jiebi/CodeConvo huggingface dataset:
Change:
location-specific content (such as retrieving tiles of a map display). <ins> In addition to these limitations, security describes operational constraints that are necessary to realize the goals of the protocol. </ins> 2.2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Discussion:
This talks about the odd case where target and gateway are separate. The primary insight here is that the target is just a regular HTTP resource and the requests from the gateway aren't special. Problems only occur if the gateway is privileged in some way. If abuse comes via the gateway, then the target would ordinary block the client, which tends to affect a bunch of bystanders in this model. So there is pressure to do something special for the gateway. In that case, the target is trusting the gateway in some way. Explain that. The heading here is the only case where we use the short names of the entities, but I can't stand short headings.
The changes are a big step forward in the right direction, but the flow seems a little weird as the text in the first part of the security section is about co-located gateway/target. Strongly suggest to move the added new text at the end of the whole section and add a forward reference in the text: (from the intro in the security section)
And, just to be clear, the PR text addresses my concern. My comment about the flow is just editorial.
I've taken the suggestion to move the text (with forward references) and made a few tweaks: Rebased. Moved and rewritten some text from the top of the security considerations that better fit the new section. Added a forward reference to this section. Moved and rewritten text added in to the applicability section. (Originally this was just to correct a misspelling, but I think this makes more sense in the new home.) NAME can you double-check my work. With this, I think we're ready to revise the draft and ask the IESG to finalize their ballot.
Change:
The signature effectively binds the credential to the parameters of the handshake in which it is used.  In particular, it ensures that <del> credentials are only used with the certificate, protocol, and signature algorithm chosen by the delegator.  Minimizing their semantics in this way is intended to mitigate the risk of cross protocol attacks involving delegated credentials. </del> <ins> credentials are only used with the certificate and signature algorithm chosen by the delegator.  Minimizing their semantics in this way is intended to mitigate the risk of cross protocol attacks involving delegated credentials. </ins> The code changes to create and verify delegated credentials would be localized to the TLS stack, which has the advantage of avoiding

Discussion:
As discussed in URL and subsequent.
I have responded to the two comments. No idea why CI is busted.
looks like the CI segfaulted :) I'll manually test locally and merge
Please add yourself to acknowledgements as well. remove change in line 192 as well "Each delegated credential is bound to a specific version of TLS and signature". somehow i cant comment on changes that you haven't made. Dear TLS WG, While we were implementing delegated credentials we came up with the following two problems. I thank David Benjamin for communicating the first to me. The first is that a delegated credential is pinned to a particular version of TLS. Unfortunately this means that the rollout of a new version of TLS (which libraries consider that they can do on their own) makes an existing set of delegated credentials unusable, and the signer of delegated credentials needs to accept a new version of TLS as valid before the extension can be used with a new version. This is similar to the issues prompting draft-wood-tls-external-psk-importer-00 where PSKs depend on negotiated parameters, and thus are difficult to use in practice. The second is that the DelegatedCredential indicates the algorithm that was used to sign it. Someone who is a bit careless when implementing might take that literally with the result that they verify a DelegatedCredential with RSA algorithm and the certificate is really an ECDSA certificate. I'll submit a PR with text for security considerations/rewording the verification steps. Sincerely, Watson
Change:
4.2. Entropy properties of external PSKs may also affect TLS security <del> properties.  In particular, if a high entropy PSK is used, then PSK- only key establishment modes are secure against both active and passive attack.  However, they lack forward security.  Forward security may be achieved by using a PSK-DH mode. </del> <ins> properties.  For example, if a high entropy PSK is used, then PSK- only key establishment modes provide expected security properties for TLS, including, for example, including establishing the same session keys between peers, secrecy of session keys, peer authentication, and downgrade protection.  See RFC8446, Section E.1 for an explanation of these properties.  However, these modes lack forward security. Forward security may be achieved by using a PSK-DH mode, or, alternatively, by using PSKs with short lifetimes. </ins> In contrast, if a low entropy PSK is used, then PSK-only key establishment modes are subject to passive exhaustive search attacks

Discussion:
NIT: Might be better to say: Just drops some redundant words.
I think some things that should be more positive: -- For both PSK authentication and PSK key exchange without (EC)DHE the bad security properties such as lack of identity protection and lack of forward secrecy can be overcome by using one-time PSKs. External PSKs with short lifetimes are quite common in many real deployments. I think this should be mentioned. -- I think quantum resistance should be mentioned earlier in the document. Quantum resistance is a security property, not use a use case. Some things that should be more negative: -- In the list in 4.1 you can add "4. Any group member can blame any other group member." Other comments: -- "then PSK-only key establishment modes are secure against both active and passive attack." I think this you need to describe the exact attacks you have in mind rather than use the work "secure". My view would be that acceptable security in 2021 includes both identity protection and forward secrecy. But more on a system level, then necessarily by TLS itself. -- "DH" I think it would be good to change all “DH” to “DHE” and all “Diffie-Hellman” to “ephemeral Diffie-Hellman” to avoid confusion with the static DH cipher suites in obsolete versions of TLS. -- "As discussed in Section 6, there are use cases where it is desirable for multiple clients or multiple servers to share a PSK." "However, as discussed in Section 6, there are application scenarios that may rely on sharing the same PSK among multiple nodes." Unless you have any real deployments to share, I think this should be reformulated. These are Gedankenexperiments used to illustrate the attack, not real-world applications. I would reformulate and remove "desirable", group PSKs should be very much discouraged. Suggestion: "As discussed in Section 6, to illustrate their attack, [Akhmetzyanova] describes scenarios where multiple clients or multiple servers share a PSK."
Change:
the inclusion of invalid characters in field names or values. <del> A request or response that includes payload data can include a Content-Length header field.  A request or response is also malformed if the value of a Content-Length header field does not equal the sum of the DATA frame lengths that form the payload data.  A response that is defined to have no payload, as described in Section 6.4 of SEMANTICS, can have a non-zero Content-Length field, even though no </del> <ins> A request or response that is defined as having content when it contains a Content-Length header field (Section 6.4.1 of SEMANTICS), is malformed if the value of a Content-Length header field does not equal the sum of the DATA frame lengths received.  A response that is defined as never having content, even when a Content-Length is present, can have a non-zero Content-Length field even though no </ins> content is included in DATA frames. Intermediaries that process HTTP requests or responses (i.e., any

Discussion:
… avoiding confusion with individual frame payloads (editorial). This is related to the Semantics issue URL
NAME has created URL on http-core Semantics draft, which describes how the term "payload" is overloaded when considered with the H2 and H3 docs. Roy's has a proposal to change that term in Semantics, which impacts the HTTP/3 draft. But he was kind enought to submit PR URL, which demonstrates the impact of that change. This issue is mainly for visibility and tracking purposes.
With or without NAME suggestion. I need to do the same for h2, so it is good to see URL suggestion
Change:
12.1.  URIs <del> [1] https://mailarchive.ietf.org/arch/search?email_list=ietf-and- github </del> <ins> [1] https://github.com/ </ins> <del> [2] https://github.com/ietf-gitwg/using-github </del> <ins> [2] https://git-scm.com/ </ins> <del> [3] https://github.com/ </del> <ins> [3] https://bitbucket.org/ </ins> <del> [4] https://git-scm.com </del> <ins> [4] https://about.gitlab.com/ </ins> <del> [5] https://github.com/ </del> <ins> [5] https://www.ietf.org/about/note-well/ </ins> <del> [6] https://bitbucket.org/ [7] https://about.gitlab.com/ [8] https://www.ietf.org/about/note-well/ [9] https://github.com/dontcallmedom/github-notify-ml </del> <ins> [6] https://github.com/dontcallmedom/github-notify-ml </ins>

Discussion:
From Adam's AD review
Note that the URL fixes here are ineffective. The source is: The resulting XML is: The HTML shows a nice clickable link. xml2rfc produces text output of "URL (URL)". Perhaps this is a case where a small tweak to xml2rfc is in order.
Nice relaxation of the text.
Change:
sending direction) up to the anti-amplification limit to probe if the path MTU (PMTU) for the new path is still acceptable. <del> 7.2. </del> <ins> 7.4. </ins> The responder MUST NOT delay sending an elicited "path_response" or "path_drop" messages.

Discussion:
Section 4 should only provide a description of the RRC messages (chal/resp & delete) and say a few words about extensibility of the feature. I think the discussion around interplay between RRC and CID should go in a separate (sub)section.
Change:
Round-trip time of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this <del> requires parsing of the QUIC packet header and the cleartext TLS handshake on stream 0. </del> <ins> requires parsing of the QUIC packet header and recognition of the handshake, as illustrated in handshake. </ins> In the common case, the delay between the Initial packet containing the TLS Client Hello and the Handshake packet containing the TLS

Discussion:
The manageability document should illustrate all the various packet sequences in a handshake, preferably with pretty pictures.
Now the transport draft has these illustrations as well. However, I think we should still at them in manageability as well. Actually I would like to try the SVG format here. Anybody in for that?
The handshake illustrations here should only concern themselves with the wire image, unlike those in the transport draft, but yes we should derive them from the transport draft. Happy to do these in ASCII as well as SVG.
The problem with examples is that they might be typical, but they rarely capture the breadth of options well. Maybe you should purposefully diverge from established practice in these to avoid certain illusions from being formed. For instance, put PADDING first.
Change:
indicates that the request has failed, and the client MUST therefore abort the request. <ins> Proxies MUST NOT introduce fragmentation at the IP layer when forwarding HTTP Datagrams onto a UDP socket.  In IPv4, the Don't Fragment (DF) bit MUST be set if possible, to prevent fragmentation on the path.  Future extensions MAY remove these requirements. </ins> 3.2. When using HTTP/1.1, a UDP proxying request will meet the following

Discussion:
An application that tunnels UDP may rely on certain properties or features of the socket that the proxy creates. The draft covers some of these but doesn't seem to mention the UDP fragmentation. TURN has a whole section on this URL QUIC, for example, requires that and recommends the Don't Fragment (DF) bit MUST be set if possible. Since a proxy is agnostic to the application protocol in use (I'm assuming that because we don't mention the anywhere) perhaps CONNECT-UDP would benefit from a signal the client can send to the proxy to state it's DF preferences.
This sounds like a worthwhile extension draft? I don't think it's required to have a functional CONNECT-UDP protocol
One argument for doing it here is that one of the common uses of CONNECT-UDP will be to tunnel QUIC, and this is an obvious footgun in consideration of RFC 9000 requirements. The opposite way to solve the problem could be to add MUST/SHOULD language about proxies setting DF by default. And then require an extension to signal to disable it. But this is solutionizing a bit. Really, I want to be able to write a client that can have consistent expectations about the way datagram payload gets sent on UDP. Otherwise when things go wrong I'm left guessing and I might not have the information that the proxy did. I could even live with text in this document that raises this as a consideration but punts on the problem.
Note that this isn't just about setting in IPv4. It's also about whether to apply sender fragmentation, in IPv6. I would be OK with declaring that all fragmentation is off by default, and leave it to extensions to turn it on.
Good point Ben!
I'd be OK with saying proxies MUST NOT explicitly add fragmentation and SHOULD set the DF bit. We can't say MUST set DF because not all operating systems allow setting the DF bit on UDP sockets.
RFC 9000 says , not a fan?
"MUST ... if possible" is the same as "SHOULD" for me, I don't much care between them.
Change:
Either "jwk" (JSON Web Key) or "kid" (Key ID) as specified below <ins> An ACME server MUST implement the "ES256" signature algorithm RFC7518 and SHOULD implement the "EdDSA" signature algorithm using the "Ed25519" variant (indicated by "crv") RFC8037. </ins> The "jwk" and "kid" fields are mutually exclusive.  Servers MUST reject requests that contain both.

Discussion:
As proposed in EKR's AD review, discussed on-list and at IETF 102.
Of course, this needs WG consensus first.
Yes NAME just posting this so we can be concrete about the discussion in the meeting.
Merging this on AD+chair guidance guidance that we can
Change:
use the next closest value instead. Finally, if this description is of type "pranswer" or "answer", <del> follow the processing defined in the sec.applying-an-answer section below. </del> <ins> follow the processing defined in sec.applying-an-answer below. </ins> 5.10.

Discussion:
This addresses Adam's actual comment - and adds the first references to rollback in the processing section - but leaves the details to be filled in by a future PR.
LGTM
Change:
8. This document requires no actions from IANA. <del> 9. The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP section 4.1 could be updated to explicitly allow mDNS names in the connection-address field. The proposal relies on adding the ability to register mDNS names at ICE gathering time.  This could be described in ICESDP and/or WebRTCSpec. The proposal allows updating IPHandling so that mode 2 is not the mode used by default when user consent is not required.  Instead, the default mode could be defined as mode 3 with mDNS-based ICE candidates. </del>

Discussion:
This work is already in motion in the desired documents.
LGTM
IOW, should this document define the new modes, or just how mDNS should be used to hide local IP addresses? If the latter, we would then also need to write a ip-handling v2 that defined the new modes, and pointed at this doc for details on how the technique should work.
From last meeting discussions, the plan was to define the new modes in this document and add a note in the ip-handling document that new modes might be defined with an informative reference to this document. I think defining the new modes in this document will also ease the authoring work and the review from the RTCWeb WG. In the long run, I think an ip-handling v2 might be a better place for the definition of the modes. For instance the guidelines around a default mode does belong in the ip-handling document, not the mdns-ice-candidate document.
OK. This particular document may be in the wrong WG then, but we can leave those details for later.
Leaving this open to cull the Specification Requirements section once it has been fully incorporated into ip-mdns-ext.
Change:
server ID is longer, a fourth pass is necessary: "right_0 = right_1 ^ truncate_right(AES_ECB(key, expand_left(left_0, <del> 0x01))) " </del> <ins> 1 + cid_len))) " </ins> and the load balancer has to concatenate left_0 and right_0 to obtain the complete server ID.

Discussion:
in accordance with the 2nd crypto review
In the second crypto review () there was a note that plaintexts of different lengths might end up with similar results, if the extra bits were zeros. The suggestion to fix this was to update the path index to also include the length.
Looks good, except for the missing parenthesis.
Change:
client, but some blocks are dropped in transmission as illustrated in B3non1. <del> The server realizes that some blocks are missing and asks for the missing ones in one go (B3non2).  It does so by indicating which blocks have been received in the data portion of the response.  The token used in the response should be the token that was used in the highest block number received payload.  The client can then derive the Request-Tag by matching the token with the sent request. </del> <ins> On seeing a payload from the next set of payloads, the server realizes that some blocks are missing from the previous MAX_PAYLOADS payloads and asks for the missing blocks in one go (B3non2).  It does so by indicating which blocks have been received in the data portion of the response.  The token used in the response should be the token that was used in the last block number received payload.  The client can then derive the Request-Tag by matching the token with the sent request. </ins> Under high levels of traffic loss, the client can elect not to retry sending missing blocks of data by "forgetting" all the tracked tokens

Discussion:
find another name than Quick-Block
A poll is ongoing. Updated to Q-Block in -02, but open to change if we get more inputs
Change:
The PTO period is the amount of time that a sender ought to wait for an acknowledgement of a sent packet.  This time period includes the <del> estimated network roundtrip-time (smoothed_rtt), the variance in the </del> <ins> estimated network roundtrip-time (smoothed_rtt), the variation in the </ins> 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,

Discussion:
It's a mean deviation. This has confused at least one reader.
True-ish, but nor is smoothed_rtt a mean. And now you have a variable with a name that bears no semblance to the concept you use to describe it. You could instead play apologist and explain that this isn't a variance in the statistical sense, but variance in a purely colloquial sense.
Section 2 of RFC2988 says "To compute the current RTO, a TCP sender maintains two state variables, SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation)." It does subsequently use the term variance in one spot, but given the original definition is a better one, I'd rather use variation than variance. RFC6298 does the exact same thing, and defines RTTVAR as "round-trip time variation".
In both sentences, minrtt and smoothedrtt are described in technically accurate terms, so I think it makes sense to describe rttvar as a mean deviation, because that's the most technically accurate term. I also understand the need for consistency, so if you have suggestions on how to improve that without removing the technical description, it'd be appreciated.
Change:
attacker. Future versions of QUIC may have different requirements for the <del> lengths of connection IDs larger than version 1.  In particular, connection IDs might not be required to have a minimum lengths, and might be longer than 20 bytes.  A server therefore MUST respond with a Version Negotiation packets for all lengths of connection IDs allowed by the layout defined here. </del> <ins> lengths of connection IDs.  In particular, connection IDs might have a smaller minimum length or a greater maximum length.  Version- specific rules for QUIC packets therefore MUST NOT influence a server decision about whether to send a Version Negotiation packet. </ins> The remainder of the Version Negotiation packet is a list of 32-bit versions that the server supports.

Discussion:
Could we also maybe add a pointer to the requirement that a DCID in an Initial must be eight bytes to Section 17.2? Because at the moment, it's buried in Section 7.2, where I didn't find it.
I've taken this change manually, after reverting the change to the invariants doc. After looking at this more closely, the invariants doc does not include specifics of how to generate a Version Negotiation packet and this takes an awkward step in that direction. Rather than start to import the rules into invariants piecemeal like this, I think that it is cleaner to leave the rules for generating a Version Negotiation packet as version-specific, which is already clearly the case.
Addendum: I missed the bit about this being a blanket "version-specific rules for packets". I've changed this to "version-specific rules for connection IDs", to reflect the context better. And to avoid tripping up on the packet size rules in version 1.
Since future QUIC versions might have different CID length requirements for Initial packets (or however that packet type will be called in that version), we already require servers to be able to send Version Negotiation packets with CIDs longer than 20 bytes (which is the maximum length that v1 allows). We need to clarify that this also applies to the minimum CID length, which is 8 byte for the DCID in v1. A future version of QUIC might relax this limit, so a server also needs to generate a VN packet if it receives a packet with an unknown version and a shorter DCID, otherwise it won't be possible to roll out such a QUIC version. This is coming out of a Slack discussion with NAME and NAME as well as recent tests on the interop runner. It turns out that 2 server implementations on the interop runner didn't get this right, and at least one server implementation that's not on the interop runner, but is running QUIC in production.
I think the CID specific aspect is fine. It is unclear what other aspects that are specified by the protocol and are not invariant here.
Change:
fixed header (first 4 bytes of the CoAP over UDP header), which includes the length information of variable size. <del> 4-bit unsigned integer.  A value between 0 and 12 directly </del> <ins> 4-bit unsigned integer.  A value between 0 and 12 inclusive </ins> indicates the length of the message in bytes starting with the first bit of the Options field.  Three values are reserved for special constructs:

Discussion:
(1) s/between 0 and 12/& inclusive/ (2) maybe revisit the language about default values vs. origin values for CSM options:
Change:
a context that has a different origin than the top-level browsing context), or a private browsing context. <del> 4. </del> <ins> 5. </ins> <del> 4.1. </del> <ins> 5.1. </ins> The implementation of this proposal requires the mDNS querying capability of the browser for registering mDNS names or adding remote

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