jiebi/CodeConvo huggingface dataset:
Change:
(though they MUST be ACKed as usual). Endpoints MUST NOT send either of these messages if they did not <del> negotiate a connection ID. 10. Application data messages are carried by the record layer and are fragmented and encrypted based on the current connection state.  The messages are treated as transparent data to the record layer. </del> <ins> negotiate a connection ID.  If an implementation receives these messages when connection IDs were not negotiated, it MUST abort the connection with an unexpected_message alert. </ins> <del> 11. </del> <ins> 9.1. </ins> Below is an example exchange for DTLS 1.3 using a single connection id in each direction.

Discussion:
This pull request aims to address the open issues regarding sequence number encryption. The approach chosen follows the design used in QUIC.
Change:
<del> CBOR Encoded Message Syntax </del> <ins> COSE: A Message Based Security Solution for CBOR </ins> draft-ietf-cose-msg-latest Abstract

Discussion:
We change the title of the document Implement the suggested change from Carsten that we put nils in to unused elements in the ParytInfo structure. I was a bit more complete than the original suggestion but it is probably simpler to get right that way.
It may be better to use the CBOR tag 24 rather than a bstr wrapper for the protected attributes field. The major question that needs to be addressed is how this is treated by existing parsers - will they try and decode it anyway or will the wait to decode them later. It is going to be required that they are both decode later and immutable to changes if they run through an intermediary which will decode, modify and re-encode any of the top level information. I don't believe that there is any benefits to using this rather than bstr for the payload field on signatures and macs since they could be any data type inside rather than a fixed one.
Did not correctly read the spec.
Change:
desc).  This means that some RtpTransceivers that were previously associated will no longer be associated with any m= section; in such cases, the value of the RtpTransceiver's mid property MUST be set to <del> null.  RtpTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed.  However, a RtpTransceiver MUST NOT be removed if a track was attached to the RtpTransceiver via the addTrack method.  This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. </del> <ins> null, and the mapping between the transceiver and its m= section index MUST be discarded.  RtpTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed.  However, a RtpTransceiver MUST NOT be removed if a track was attached to the RtpTransceiver via the addTrack method.  This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. </ins> A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or

Discussion:
Also describing explicitly what it means for an RtpTransceiver to be "associated" with an m= section. Namely, that it has a mid attribute that matches the MID of that m= section. Addresses issue .
There probably are better ways of wording this, I'm open to suggestions.
Ekr pointed out that this doesn't handle situations where "a=mid" is not used. So I added text describing a transceiver->m= section index mapping.
I think I've addressed all of ekr and juberti's comments; ready for another review.
LGTM
Change:
9.7. <del> IANA is asked to enter two new items into the Service Names and Transport Protocol Port Number Registry, all with this document as a reference: Service name "rd" over protocol "udp", described as "Resource Directory Directory Resource accessed using CoAP" </del> <ins> IANA is asked to enter a new item into the Service Names and Transport Protocol Port Number Registry: </ins> <del> Service name "rd-lookup-res" over protocol "udp", described as "Resource Directory resource lookup accessed using CoAP" </del> <ins> Service name: "core-rd" </ins> <del> Service name "rd-lookup-ep" over protocol "udp", described as "Resource Directory endpoint lookup accessed using CoAP" </del> <ins> Protocol: "udp" </ins> <del> All share the same assignment note: </del> <ins> Description: "Resource Directory accessed using CoAP" </ins> <del> Defined TXT key: path (e.g. "path=/rd") </del> <ins> Reference: this document </ins> 10.

Discussion:
Reviewing the discussion in [1] and [2], my original patch seems to have overshot. [1]: URL [2]: URL
Much more sensibleless ambitious and more correct. The outcome in discussion in the Friday meeting was that the resource-directory specification should simply define the small number of DNS-SD service types that are needed for resource directory discovery. We said details were to be taken to the list, which I want to initiate now. In the meeting, I gave the three examples core-URL, core-rd-URL, and core-URL — noting that while core-rd is a proper RD service type, core-rd-tls isn’t. To cover the six transports we have for CoAP today (coap, coaps, coap+tcp, coaps+tcp, coap+ws, coaps+ws), we would need four service types on top of tcp and could use two of them over udp? Grüße, Carsten
Change:
1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </del> <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 2.

Discussion:
— Section 1.1 — Please use the new BCP 14 boilerplate from RFC 8174.
Change:
channels.  This is performed via DTLS RFC6347 and DTLS-SRTP RFC5763 keying for SRTP RFC3711 for the media channel and SCTP over DTLS RFC8261 for data channels.  Specifically, Alice and Bob perform a <del> DTLS handshake on every channel which has been established by ICE. </del> <ins> DTLS handshake on every component which has been established by ICE. </ins> The total number of channels depends on the amount of muxing; in the most likely case we are using both RTP/RTCP mux and muxing multiple media streams on the same channel, in which case there is only one

Discussion:
RFC 5764 rather optimistically describes how the same DTLS handshake can be used to key SRTP for RTP and RTCP even if these are on different components (i.e., is not negotiated). This is not what anyone does. Mandate precisely one handshake per component.
FROM IETF100: Don't mux.
Given we don't allow rtcpmux in WEbRTC. This is sort of irrelevant and we can say it never happens just don't do it.
I actually thought this was pretty clear before, but I've added the term component to make it clear. I don't understand NAME comment. We absolutely allow rtcpmux in WebRTC, but it's still possible to not have it (browsers aren't forbidden to support it).
Change:
examine each of the datagrams in detail. The QUIC handshake can normally be recognized on the wire through at <del> least four datagrams we'll call "QUIC Client Hello", "QUIC Server Hello", and "Initial Completion", and "Handshake Completion", for purposes of this illustration, as shown in fig-handshake. </del> <ins> least four datagrams we'll call "Client Initial", "Server Initial", and "Client Completion", and "Server Completion", for purposes of this illustration, as shown in fig-handshake. </ins> Packets in the handshake belong to three separate cryptographic and transport contexts ("Initial", which contains observable payload, and

Discussion:
least four datagrams we'll call "QUIC Client Hello", "QUIC Server Hello", and "Initial Completion", and "Handshake Completion", for purposes of this illustration, as shown in {{fig-handshake}}. I mean, you can call them that for reference purposes, but there's no such thing as a "QUIC Client Hello" (or ClientHello). Calling something "Initial Completion" when it might not contain any Initial packets might confuse people when they go looking for more details. Maybe "Client Initial," "Server Initial," "Client Finished," and "Server Finished"? It mixes layers, but those are at least things that occur in the referenced packets.
Or, to avoid using TLS message names consistently, s/Finished/Confirmation
Should I conclude from the absence of comment since February that we are all reasonably content with "Client Initial", "Server Initial", "Client Completion", and "Server Completion"? If so I'm happy to create the PR to save Brian a job. But I don't want to do that if these are not the best names.
This was assigned to Brian has he wanted to take a stab.
That's fine I'll leave it to Brian.
Change:
administrative notifications or logs in the advent of unexpected HTTP 401 (Unauthorized) responses from the MASA. <ins> In order to support multi-tenant MASA implementations the Registrar SHOULD include the RFC6066 Server Name Indicator. </ins> 5.4. When a Registrar receives a Pledge voucher-request it in turn submits

Discussion:
Adds text to include SNI in BRSKI-MASA handshake.
I like the first diff (expanding the client authentication discussion into a paragraph). I don't see the need for RFC6066 SNI reference. But since it is a "SHOULD" don't have a technical complaint.
Change:
choosing the candidates to be raced, selecting appropriate transport parameters, etc.  An application SHOULD NOT depend on specific caching behaviour, instead it ought to explicitly request <del> any requid or desired properties via the Transport Services API. </del> <ins> any required or desired properties via the Transport Services API. </ins> 4.2.1.

Discussion:
Don't just rely on the cache .
URL I think we should be very specific that the application SHOULD not expect certain caching behavior or MAY expect a minimum set of information cached. This is also related to the expectancy from application to expect same protocol given same properties and security parameter each time. will such input generate same consistent out put from one TAPS system?
I suggest adding this explicitly - something like: This caching does not imply that the same decisions are necessarily made for subsequent connections, rather, it means that cached state is used by the Transport Services architecture to inform functions such as choosing the candidates to be raced, selecting appropriate transport parameters, etc.
See PR on request required properties , which could close this issue.
Thought resolved by merged PR in latest editor version.
NAME Does the merged text in master address issue ?
LGTM, Thansk.
Very nice (IMHO)!
Change:
identified by concatenating its integer to it's parents identifier with a dot in between, such as "1.1" and "1.2".  Each node will be summarized by a tuple of three elements: endpoint, path (labeled here <del> by interface), and protocol.  The above example can now be written more succinctly as: </del> <ins> by interface), and protocol.  In protocol stacks, the layers are separated by '/' and ordered top-down.  The above example can now be written more succinctly as: </ins> When an implementation is asked to establish a single connection, only one of the leaf nodes in the candidate set is needed to transfer

Discussion:
Fixes Issue
URL We have given example but we haven't really defined how the format should be written or how one should interpret in the example. Here "Any Stream" means any protocol that supports streaming ... but it would take quit some time to get to that point . It is also confusing that an "Any" is used with comma (,) and another is without a comma... To understand the example correctly, I suggest we either keep the examples on to a level where this is already described or describe how we are formatting the expression in this document as we described tree structure with numeric ( for example 1 , 1,1 ).
Perhaps we can just write HTTP and Stream without the Any part? Alternatively we could add a specific interface, e.g Wi-Fi, to avoid the first Any. And then also clarify the description of the example and what is raced. The notation is described earlier in the text, so I assume that is not the problem?
If you propose the changes then I can perhaps understand it better about the modified example.
NAME does PR solve the issue for you?
Thanks for the PR. I put two comments as input. I am fine merging it once Tommy's questions are resolved.
Change:
the result often has undesirable performance consequences, incomplete coverage, or both. <del> The design in this document takes a different approach: it assumes that private origins will co-locate with or hide behind a provider (CDN, application server, etc.) which can protect SNIs for all of the domains it hosts.  As a result, SNI protection does not indicate that the client is attempting to reach a private origin, but only that it is going to a particular service provider, which the observer could already tell from the visible IP address. The design in this document introduces a new extension, called Encrypted Client Hello (ECH), which allows clients to encrypt the entirety of their ClientHello to a supporting server.  This protects the SNI and other potentially sensitive fields, such as the ALPN list.  This extension is only supported with (D)TLS 1.3 RFC8446 and newer versions of the protocol. </del> <ins> The protocol specified by this document takes a different approach. It assumes that private origins will co-locate with or hide behind a provider (reverse proxy, application server, etc.) that protects SNIs for all of the domains it hosts.  As a result, SNI protection does not indicate that the client is attempting to reach a private origin, but only that it is going to a particular service provider, which the observer could already tell from the visible IP address. This document specifies a new TLS extension, called Encrypted Client Hello (ECH), that allows clients to encrypt their ClientHello to a supporting server.  This protects the SNI and other potentially sensitive fields, such as the ALPN list RFC7301.  This extension is only supported with (D)TLS 1.3 RFC8446 and newer versions of the protocol. </ins> 2.

Discussion:
Use the term "plaintext" consistently. Be consistent about the number of spaces following a period. (We'll go with one.) Editorial changes to Sec.1-3.
Change:
queries, announcement responses, resolution queries, and goodbye responses associated with mDNS. <del> 4.2. </del> <ins> 5.2. </ins> If the optional probing queries are implemented for the name registration, a malicious endpoint in the local network, which is

Discussion:
PR of
Added a 'good' example as well, and put them all in an examples section. PTAL.
Will merge once I get a second approval.
Some of this stuff is complicated, example diagrams can help.
Great to have examples. Regenerating the html, the examples do not show up in full on the html version, probably not a big deal, the txt version is fine.
LGTM
Change:
existing transport connection using the Destination Connection ID field (see also connid) in the QUIC header.  This supports cases where address information changes, such as NAT rebinding, intentional <del> change of the local interface, or based on an indication in the handshake of the server for a preferred address to be used. </del> <ins> change of the local interface, the expiration of a temporary IPv6 address RFC8981, or the server indicating a preferred address Section 9.6 of QUIC. </ins> Use of a non-zero-length connection ID for the server is strongly recommended if any clients are behind a NAT or could be.  A non-zero-

Discussion:
Should there be a section about temporary address extension for IPv6 addresses RFC 8981 (as some OS can be very aggressive in changing to the next IPv6 address) ? Or is it 'just' a case of NAT rebinding ? If the latter, then one sentence in the introduction could be useful. What is the recommendation for these addresses, should the application keep always the first address as long as it is valid ? or should it switch to a new one ? [MK] I don't think this a problem as the address is usually (at least today) not changed during an on-going connection, or? EV> the previously used address may have become invalid (i.e., has expired) but this would only happen on very long-lasting connections. But my question is still the same: should the QUIC application tries to keep the 'original' address or should it try to use the most recent one? Giving guidance would be desirable?
Change:
[45] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/109 [46] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/110 <del> [47] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/112 [48] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/113 </del>

Discussion:
remove OAuth DPoP binding. Described why on IETF mailing list: OAuth PoP: expired draft, due to be replaced with new draft based on HTTP Message Signatures. Also closing and
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: a47cdeabae554f3636d63a0ce8e0f8b52ff53693 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Removed autoindent in my editor to fix the issue
OAuth Proof of Possession (PoP): Editor's note: This is a stale draft from the OAuth working group, but it does at least provide some basic functionality for protecting HTTP messages with a signature. This work is likely to be subsumed by the general-purpose HTTP message signature mechanism in Section 8.5.
OAuth Proof of Possession (PoP): Editor's note: This is in contradiction to the referenced spec which makes this field mandatory.
Change:
1. <del> Elliptic Curve Cryptography (ECC) is emerging as an attractive </del> <ins> Elliptic Curve Cryptography (ECC) has emerged as an attractive </ins> public-key cryptosystem, in particular for mobile (i.e., wireless) environments.  Compared to currently prevalent cryptosystems such as RSA, ECC offers equivalent security with smaller key sizes.  This is

Discussion:
Added new curves and new authors. Partial merge of draft-ietf-tls-curve25519
Change:
the request. The process by which the delegation happens is known as a grant, and <del> the GNAP protocol allows for the negotiation of the grant process over time by multiple parties acting in distinct roles. </del> <ins> GNAP allows for the negotiation of the grant process over time by multiple parties acting in distinct roles. </ins> This protocol solves many of the same use cases as OAuth 2.0 RFC6749, OpenID Connect OIDC, and the family of protocols that have grown up

Discussion:
I attempted to rephrase all occurrences of the redundant "GNAP protocol" in a way that made sense. Most of the time it was changing "the GNAP protocol" to just "GNAP", but there are a few cases where it sounded weird and required some more context.
Change:
be used with any permitted hash algorithm, subject to restrictions in the certificate, if any.  RSA signatures MUST be based on RSASSA-PSS, regardless of whether RSASSA-PKCS-v1_5 appears in <ins> "signature_algorithms".  SHA-1 MUST NOT be used in any signatures in CertificateVerify, regardless of whether SHA-1 appears in </ins> "signature_algorithms". 6.3.9.

Discussion:
This completes the removal of SHA-1 for CertificateVerify. There's no reason to allow it there at all
LGTM
Change:
Where Hash is the authenticator hash defined in section 4.1.  If the authenticator request is not present, it is omitted from this <del> construction (that is, it is zero length). </del> <ins> construction, i.e., it is zero length. </ins> If the party that generates the exported authenticator does so with a different connection than the party that is validating it, then the

Discussion:
This changes a lot of text, since many places (perhaps rightfully so) assume the contents of the Certificate message are a normal X509 certificate. Some uses of EAs might just use the Certificate message as a vehicle for other identifying information. Thus, rather than box ourselves into a corner, this change generalizes the purpose of this Certificate to be that of an identity. Addresses .
The document's currently written in such a way that one might assume it can only be used to authenticate additional certificates. For example, the introduction states: (emphasis mine!) However, [1] suggests that other authentication mechanisms are possible. (Meta observation and question: what are the contents of the Authenticator messages in the OPAQUE EA flow? Section 6 discusses the possibility of an empty Authenticator, but the OPAQUE flow uses the extension to provide the server response. What OPAQUE seems to require is an empty but non-empty .) Perhaps we should generalize certificate-based authentication to arbitrary challenge-response authentication mechanisms? [1] URL
cc NAME
Change:
offering clients an alternative type of challenge such as CAPTCHA for accessing a resource. <ins> For example, consider a scenario in which the client is a web browser, and the origin can accept either a token or a solution to a puzzle intended to determine if the client is a real human user.  The origin would send clients a 401 HTTP response that contains a token challenge in a "WWW-Authenticate" header field along with content that contains the puzzle to display to the user.  Clients that are able to respond with a token will be able to automatically return the token and not show the puzzle, while clients that either do not support tokens or are unable to fetch tokens at a particular time can present the user with the puzzle. </ins> To mitigate the risk of deployments becoming dependent on tokens, clients and servers SHOULD grease their behavior unless explicitly configured not to.  In particular, clients SHOULD ignore token

Discussion:
NAME can you give this a quick look and merge if you're OK with it?
I'll just merge it and we can revise if needed
If a server wants to use this auth scheme but the client doesn't support it, what's supposed to happen? Do you have a way for the server to discover that the client does support it?
If the client doesn't support the scheme, it will ignore challenges — this is the same as cases where the client doesn't support a particular token type, or it fails to fetch a token for any reason. This has a useful privacy property in that it doesn't leak information about if the client couldn't fetch a token or if just doesn't support tokens, or chooses not to try to fetch a token.
We do comment on server behavior here:
We can give a simple example where the origin sends a 401 response with a body that is a CAPTCHA, such that clients that don't support this see that instead of using a token.
An example like that would be good, but this makes me wonder: did we ever consider expressing the client's capability to support this token via a CH? I don't remember if we did or not.
I think adding a new fingerprinting surface for that in CH isn't great. There's talk instead of having a javascript capability API for the support.
I don't really think the fingerprinting concern is that significant. If a client supports it, then a server can more than likely (with very high probability) just probe it for a token and confirm its guess. The lack of a hint just makes the server's life more difficult without offering any meaningful privacy improvement to the client. In principle, the less signals the better, but this is a signal that can be determined anyway.
To be clear, I'm not suggesting that we actually propose a CH for this. I'm just raising the thought experiment.