jiebi/CodeConvo huggingface dataset:
Code change:
systems and use cases, this identity may become a persistent tracking identifier. <ins> Note also that ImportedIdentity.context is visible in cleartext on the wire as part of the PSK identity.  Unless otherwise protected by a mechanism such as TLS Encrypted ClientHello ECH, applications SHOULD not put sensitive information in this field. </ins> 9. This specification introduces a new registry for TLS KDF identifiers,

Related discussion:
text: I think it may be useful to call out that the "multiple clients" and "multiple servers" case can occur even when there are only two endpoints that know the key (that is, when they do not have predetermined client/server roles). struct { opaque clientmac; opaque server_mac; } Context; We may not need the whole 16k to hold a MAC address, especially since this is just an example. If an attacker then redirects a ClientHello intended for one node to a different node, the receiver will compute a different context string and the handshake will not complete. Similarly to the above, this could be "a different node (including the node that generated the ClientHello)".
Code change:
brotli, the Certificate message MUST be compressed with the Brotli compression algorithm as defined in RFC7932. <ins> It is possible to define a certificate compression algorithm that uses a pre-shared dictionary to achieve higher compression ratio. This document does not define any such algorithms. </ins> If the received CompressedCertificate message cannot be decompressed, the connection MUST be torn down with the "bad_certificate" alert.

Related discussion:
text: State explicitly that we do not define any compression dictionaries. Explain the rationale behind the uncompressed_length field. Addresses comments from John Mattsson on the list.
Actually, I have a small nit.
Code change:
a host which only functions as an ACME server could place the directory under the path "/". <ins> If the ACME server does not implement pre-authorization (Section 7.4.1) it MUST omit the "newAuthz" field of the directory. </ins> The object MAY additionally contain a field "meta".  If present, it MUST be a JSON object; each field in the object is an item of metadata relating to the service provided by the ACME server.

Related discussion:
text: In Section 7.4.1 "Pre-Authorization" the spec says: If a CA wishes to allow pre-authorization within ACME, it can offer a "new authorization" resource in its directory by adding the field "newAuthz" with a URL for the new authorization resource. That text indicates that the CA may wish to not support pre-authorization in which case the "newAuthz" resource will not be present in the directory. One example of an ACME CA choosing to not support pre-authorization is Let's Encrypt. This commit clarifies the "newAuthz" field of the directory is optional in Section 7.1.1 "Directory" where a developer is likely to look to understand which resources must be supported/present in the directory and which are optional ("meta", "newAuthz"). If the server doesn't support pre-authorization it MUST omit the "newAuthz" field.
Code change:
value and the receiving member's known identity.  See Selfie for details. <del> To illustrate the rerouting attack, consider the group of peers who know the PSK be "A", "B", and "C".  The attack proceeds as follows: </del> <ins> To illustrate the rerouting attack, consider three peers, "A", "B", and "C", who all know the PSK.  The attack proceeds as follows: </ins> "A" sends a "ClientHello" to "B".

Related discussion:
text: Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.
Code change:
problem.  The "type" and "detail" fields MUST be populated.  To facilitate automatic response to errors, this document defines the following standard tokens for use in the "type" field (within the <del> "urn:acme:" namespace): </del> <ins> "urn:ietf:params:acme:error:" namespace): This list is not exhaustive.  The server MAY return errors whose "type" field is set to a URI other than those defined above.  Servers MUST NOT use the ACME URN namespace for errors other than the standard types.  Clients SHOULD display the "detail" field of such errors. </ins> Authorization and challenge objects can also contain error information to indicate why the server was unable to validate

Related discussion:
text: In addition to adding the error, as proposed in , this PR fixes some issues discussed in the F2F meeting, namely moving ACME URNs under the IETF parameters space, and having errors be a sub-namespace of an overall ACME namespace.
Code change:
cause long timeout-based delays before this problem is detected by the endpoints and the connection can potentially be re-established. <del> QUIC endpoints support address migration and a QUIC connection can survive a change of the IP address or ports by mapping the connection ID, if present, to an existing connection.  Ideally a new connection ID is used at the same time when the address/port changes to avoid linkability.  As new connection IDs belonging to the same connection are not known to on-path devices, network devices are not able to map QUIC connections after a 4-tuple change.  As such, when the 4-tuple changes, stateful devices lose their state and break connectivity if state is required for forwarding, while the endpoints would otherwise survive such a change. </del> Use of connection IDs is specifically discouraged for NAT applications.  If a NAT hits an operational limit, it is recommended to rather drop the initial packets of a flow (see also sec-

Related discussion:
text: This paragraph is redundant with the previous paragraph, however, not sure I removed the right one now...
Code change:
unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. <del> Create an initial, partial GroupInfo object reflecting the following values: Group ID: The group ID for the group Epoch: The epoch ID for the next epoch Tree: The group's ratchet tree after the commit has been applied Prior confirmed transcript hash: The confirmed transcript hash for the current state of the group (not the provisional state) </del> Create a DirectPath using the new tree (which includes any new members).  The GroupContext for this operation uses the "group_id", "epoch", "tree", and "prior_confirmed_transcript_hash"

Related discussion:
text: This PR adapts the Welcome logic so that the new joiners get their path secrets directly, rather than from a DirectPath. This cleans things up in a few ways. The new joiners no longer have to have the context for the previous epoch (which was used to encrypt the DirectPath). And we can get away with one HPKE operation per new joiner instead of two (one for the EncryptedKeyPackage and one for the DirectPath). The major cost is that there's a bit more complexity in the TreeKEM. Instead of just producing and consuming DirectPaths, you now need to know which path secrets go with which nodes. You also need tree math to identify the common ancestor of two leaves, but there's a simple closed-form formula for that, expressed in the Python code here.
NAME - Curious if this seems implementable to you. Clearly it's possible, since I did it in Go :) But it also needs to make sense to other people.
Code change:
Change controller: n/a <del> 4.  References </del> <ins> 3. Security requirements for both media type and media type suffix registrations are discussed in Section 4.6 of MEDIATYPE. </ins> <del> 4.1.  URIs </del> <ins> 4. This specification defines the following new Internet media types MEDIATYPE. IANA has updated the "Media Types" registry at https://www.iana.org/assignments/media-types [3] with the registration information provided below. 5.  References 5.1.  URIs </ins> [1] https://mailarchive.ietf.org/arch/browse/httpapi/ [2] https://github.com/ioggstream/draft-polli-rest-api-mediatypes <ins> [3] https://www.iana.org/assignments/media-types </ins>

Related discussion:
text: introduce numbered sections for YAML NAME since each media type is defined in its IANA consideration, would it be ok for you if we just add a section for YAML? Feel free to PR with another proposal.
NAME could you PTAL ? :)
to be honest, i prefer definitions to have URIs and not just registrations. but if we have URIs, that's already a lot better than not having URIs! thanks!
it's maybe just OCD (and because it's very useful for URL to have linkable references) but i think it's nice to have numbered sections for everything that's being defined in the spec. in this case, i suggest to have a numbered section for each of the four media types, and to have a brief explanation of what it identifies. that way, each definition is self-contained and can be easily referenced when necessary. NAME NAME
Code change:
Upon receipt of a HelloRetryRequest, the client MUST verify that the extensions block is not empty and otherwise MUST abort the handshake <del> with a "decode_error" alert.  Clients SHOULD abort the handshake with an "unexpected message" if the HelloRetryRequest would not result in any change in the ClientHello or in response to any second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). </del> <ins> with a "decode_error" alert.  Clients MUST abort the handshake with an "illegal_parameter" alert if the HelloRetryRequest would not result in any change in the ClientHello.  If a client receives a second HelloRetryRequest in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest), it MUST abort the handshake with an "unexpected_message" alert. </ins> Otherwise, the client MUST process all extensions in the HelloRetryRequest and send a second updated ClientHello.  The

Related discussion:
text: On Tuesday, October 11, 2016 08:14:32 pm Martin Thomson wrote: or missing_extension
I think that missingextension would be OK, but we would hit the lower-level decodeerror first, since HRR is defined with:
Code change:
constructing and processing an . The Nenc parameter corresponding to the KEM used in HPKE can be found <del> in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. </del> <ins> in HPKE or the HPKE KEM IANA registry [1].  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. </ins> 4.2.

Related discussion:
text: From NAME Can we (additionally or in replacement) point to the "HPKE KEM Identifiers" IANA registry created from this table instead? Same for this and "HPKE AEAD Identifiers" registry.
Code change:
A specialized feature could be required by an application only when using a specific protocol, and not when using others.  For example, <del> if an application is using UDP, it could require control over the checksum or fragmentation behavior for UDP; if it used a protocol to frame its data over a byte stream like TCP, it would not need these options.  In such cases, the API ought to expose the features in such a way that they take effect when a particular protocol is selected, but do not imply that only that protocol could be used.  For example, if the API allows an application to specify a preference to use a partial checksum, communication would not fail when a protocol such as TCP is selected, which uses a checksum covering the entire payload. </del> <ins> if an application is using TCP, it could require control over the User Timeout Option for TCP; these options would not take effect for other transport protocols.  In such cases, the API ought to expose the features in such a way that they take effect when a particular protocol is selected, but do not imply that only that protocol could be used.  For example, if the API allows an application to specify a preference to use the User Timeout Option, communication would not fail when a protocol such as QUIC is selected. </ins> Other specialized features, however, could be strictly required by an application and thus constrain the set of protocols that can be used.

Related discussion:
text: Addresses
The architecture draft uses UDP checksums as an example of a protocol-specific property in Section 3.2 and 4.1.2. I find this a bit confusing because in the Interface draft, checksum coverage is a Generic Connection Property (Section 11.1.2). Should we maybe use a different example of a protocol-specific property, such as the TCP User Timeout we have in the Interface draft?
Sure, we can switch the example around
Thanks, LGTM!Thanks – works
Code change:
The attacker intercepts the message and redirects it to "C". <del> "C" responds with to "A". </del> <ins> "C" responds with a "ServerHello" to "A". </ins> "A" sends a "Finished" message to "B".  "A" has completed the handshake, ostensibly with "B".

Related discussion:
text: Changes to comments from Russ Housley on 03-Mar-2020
Section 3.1.1: The text says: C responds with to A. I think that C responds with a ServerHello to A. Section 3.1.2: The text says: A sends a ClientHello to B, without including a key share. It would be helpful to say "without including a key share extension." Section 3.1.3: I think a bit more explanation is needed here. Nonces can make the keys different, why doesn't the nonce from the uncompromised party help in this example? Section 4: I would like to see a bit more context here. I agree with the recommendations for the intended environment, but they are overkill in the environment suggested by draft-ietf-tls-tls13-cert-with-extern-psk. In fact, they are overkill if (EC)DH is combined with the PSK at all. So, maybe we just need to say that the PSK is not combined with a pairwise key that these rules apply.
Fixed by .
LGTM -- thanks, Russ!
Code change:
The entries in the following table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA. </del> <ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins>

Related discussion:
text: IANA's review wanted to know whether the 148 quadrillion GREASE values should be listed on the registry page as Reserved, and what note should be present if not. They should not, lest it be challenging to actually download the registry page within the lifetime of the human race. This rewords the restriction and clarifies that the restriction should be the note.
NAME Can you add the same text to 22.2 (Transport parameter registry) in the transport doc as well?
NAME said
We believe the note, updated based on IANA feedback during Last Call, is sufficient. Reserving 148 quadrillion values in the registry would cause the registry to be impossible to download in the lifetime of humanity; see . The purpose is described in , to exercise the requirement to ignore unknown frame types (a.k.a. GREASE). Proposal is to make no change; this was already covered during IANA review.
If IANA has agreed, then I am fine with it. BTW, I was not asking to make those zillions of reservations but leaving a note in the registry ;-)
It's a fair question but the WG and the responsible AD are satisfied with our IANA considerations at this stage, closing with no action.
Please see the for full context. This issue is tracking the following IANA question:
Copying my e-mail reply here: unknown values; having an explicit list encourages an explicitly defined reaction. This also applies to and , where the latter has better wording.
NAME replied to IANA . Closing this issue.
Actually, NAME said in response to the e-mail that this guidance should be in the document: Let's re-open to track. I don't think all instances of this question need separate issues, though.
So the related questions were: Should the GREASE values be listed in the registry as Reserved? No, because some rough estimation suggests it would take a few millennia to download the registry page if this were the case. Should there be a note indicating which values cannot be assigned? I'm of two minds, because while I really don't want people embedding the formula into their parsers, I do want people embedding the formula into their generators. says no Reserved listing, yes note.
I think this is proposal ready. Forwarding Mike's response to the list, to there is an archive to link to. Lars >
Code change:
If a stream is canceled after receiving a complete response, the client MAY ignore the cancellation and use the response.  However, if a stream is cancelled after receiving a partial response, the <del> response SHOULD NOT be used.  Only idempotent actions (such as GET, PUT, or DELETE) can be safely retried; a client SHOULD NOT </del> <ins> response SHOULD NOT be used.  Only idempotent actions such as GET, PUT, or DELETE can be safely retried; a client SHOULD NOT </ins> automatically retry a request with a non-idempotent method unless it <del> has some means to know that the request semantics are actually idempotent, regardless of the method, or some means to detect that the original request was never applied.  See Section 8.2.2 of SEMANTICS for more details. </del> <ins> has some means to know that the request semantics are idempotent independent of the method or some means to detect that the original request was never applied.  See Section 8.2.2 of SEMANTICS for more details. </ins> 4.1.3.

Related discussion:
text: Fixes several nits from the gen-art review, which basically all come down to defining terms appropriately and/or referencing their definitions. modifies definition of "stream" and "stream error"; pulls in more terms from SEMANTICS references SEMANTICS for definition of fields rewords to avoid the term "hop" and describes intermediation more explicitly rewords to avoid saying "not possible" and copies language from SEMANTICS advising against retries updates reference to definition of CONNECT in SEMANTICS. NAME your review would be appreciated.
In the HTTP genart review, NAME writes:
Yes, CONNECT only supports TCP, and there's no short-term plan to change that. There is separate relevant work such as but I don't think we need to change anything in the draft here - it pretty clearly mentions TCP so I don't see any ambiguity.
This question should be addressed by the definition of CONNECT the spec is referring to. It's worth double-checking the references in that section, though; it points to HTTP11, when I think there should be a definition in SEMANTICS.
In the HTTP genart review, NAME writes:
Presumably a reference into SEMANTICS; I'll look for the right section to point to.
In the HTTP genart review, NAME writes:
In the HTTP genart review, NAME writes:
In the HTTP genart review, NAME writes: "HTTP/3 stream". Perhaps it's worth defining "HTTP/3 stream" explicitly, in analogy to "HTTP/3 connection". Perhaps it's worth defining "message", too (this is only an HTTP concept, correct?). The document should make sure it clearly distinguishes terms and concept of QUIC vs. of HTTP/3 in all cases. In particular, what is the relationship between HTTP/3 frames and QUIC frames? It's important to make their difference and relationship explicit, as the document uses several other terms interchangeably between HTTP/3 and QUIC, like "connection" and perhaps "stream".
A few minor suggestions, but this is a good change.This looks good to me, thanks!
Code change:
previous variant in two important ways: The output tokens are publicly verifiable by anyone with the <del> Issuer public key; and </del> <ins> Issuer public key. </ins> The issuance protocol does not admit public or private metadata to bind additional context to tokens. <del> Otherwise, this variant is nearly identical.  In particular, Issuers provide a Private and Public Key, denoted skI and pkI, respectively, used to produce tokens as input to the protocol.  See public-issuer- configuration for how this key pair is generated. </del> <ins> The first property means that any Origin can select a given Issuer to produce tokens, as long as the Origin has the Issuer public key, without explicit coordination or permission from the Issuer.  This is because the Issuer does not learn the Origin that requested the token during the issuance protocol. Beyond these differences, the publicly verifiable issuance protocol variant is nearly identical to the privately verifiable issuance protocol variant.  In particular, Issuers provide a Private and Public Key, denoted skI and pkI, respectively, used to produce tokens as input to the protocol.  See public-issuer-configuration for how this key pair is generated. </ins> Clients provide the following as input to the issuance protocol:

Related discussion:
text: The publicly verifiable basic token issuance protocol doesn't include an origin name that the issuer can see, so it does allow origins to be able to use that issuer (as long as the know the key) without explicit coordination or permission from the issuer. This isn't necessarily a problem, but we should likely mention it.
Code change:
Internet Backbone: If a censor controls the gateways into a region, they can filter undesirable traffic that is traveling into and out of the region by sniffing and mirroring at the relevant <del> exchange points.  Censorship at this point-of-control is most </del> <ins> exchange points.  Censorship at this point of control is most </ins> effective at controlling the flow of information between a region and the rest of the Internet, but is ineffective at identifying content traveling between the users within a region. Internet Service Providers: Internet Service Providers are perhaps <del> the most natural point-of-control.  They have a benefit of being </del> <ins> the most natural point of control.  They have a benefit of being </ins> easily enumerable by a censor paired with the ability to identify the regional and international traffic of all their users.  The censor's filtration mechanisms can be placed on an ISP via

Related discussion:
text: From Stephane:
Shouldn't the CA / cert hierarchy be a point of control? For example, KZ is requiring users to install their CA, to allow them to MITM all traffic: URL Another example of CA abuse is ROA whacking, RPKI manipulation, etc.: URL
Also got this feedback from Will Scott:
Code change:
example, the Unicode PLACE OF INTEREST SIGN (U+2318) would be defined in ABNF as "%x2318". <ins> Functions are referred to using the function name followed by a pair of parentheses, as in "fname()". </ins> The terminology of RFC8259 applies except where clarified below.  The terms "Primitive" and "Structured" are used to group different kinds of values as in RFC8259; JSON Objects and Arrays are structured, all

Related discussion:
text: Use parentheses as an indication that something is a function. Also, don't confuse the reader by alluding to potential future alternatives to value(). Reviewers: is this an improvement? It's a draft PR for now until we decide the change is worthwhile.
I think we'll need to explain the () notation, which should be familiar to C programmers but not necessarily to people who grew up on other languages. I also think we have a few more examples that point to hypothetical functions, such as , , .
I don't think there's a great point at which to explain that notation and, based on your observation, I'm going off the idea.
NAME Let's see how pans out before taking the current PR any further. Once I remove the function parentheses, the two PRs are changing the same text.
would be the place.
NAME As you suggested, I introduced this in 1.1, but near the start since it's notation rather than terminology. I did a regexp search to find and fix the remaining examples (your list was complete). In doing so, I found the strange markup and removed the backticks since there was no good reason for them.
We could do the fun() explanation and completeness search in a separate PR.