jiebi/CodeConvo huggingface dataset:
Change:
Most major TLS implementations support external PSKs.  Stacks supporting external PSKs provide interfaces that applications may use <del> when supplying them for individual connections.  Details about </del> <ins> when configuring PSKs for individual connections.  Details about </ins> existing stacks at the time of writing are below. OpenSSL and BoringSSL: Applications can specify support for

Discussion:
cc NAME NAME
In section 4 there is a statement that switching the roles of servers which use PSKs will lead to weakening of security properties. As this is a common scenario today in situations where you are doing server-to-server communication, it would be useful to discuss just how and how much this weakening occurs. This was a complete surprise to me and I don't know if it was supposed to be one. Are there mitigations that can be made? In section 7, The first sentence does not read, also It seems a bit difficult to have a MUST in there when most of the items below are SHOULDs. That seems to be a dissonance. Section 7.1.1 - The idea of having domain name suffixes on PSKs seems to me to be a bad idea as this would seem to lower privacy levels. Section 7.1.2 - There seem to me to be three different places where collisions will occur. The importer function could get a collision, there could be collisions with pre-TLS 1.2 external identifiers and there could be collision with resumption keys. There has been a huge discussion about this in the EMU group and I don't find the text here to be sensible in term of whether this is or is not a problem. Section 7.1.2 - One of the things that I kept meaning to get to and just haven't done so yet, is dealing with the question of can the TLS Key binders in the handshake to distinguish between multiple keys that happen to have the same identity. Perhaps you should look to see if this does work and if it is safe.
Change:
The Client first creates a context as follows: Here, 0x0004 is the two-octet identifier corresponding to the <del> OPRF(P-384, SHA-384) ciphersuite in OPRF.  SetupPOPRFClient is </del> <ins> OPRF(P-384, SHA-384) ciphersuite in OPRF.  SetupVOPRFClient is </ins> defined in OPRF, Section 3.2. The Client then creates an issuance request message for a random value "nonce" using the input challenge and Issuer key identifier as follows: <del> The Blind function is defined in OPRF, Section 3.3.3.  If the Blind </del> <ins> The Blind function is defined in OPRF, Section 3.3.2.  If the Blind </ins> function fails, the Client aborts the protocol.  Otherwise, the Client then creates a TokenRequest structured as follows:

Discussion:
Since metadata can be bound to tokens via TokenChallenge.redemptioncontext, and the origin is ultimately the one who determines what metadata is supported, there's no more real need for the issuer_ to supply this metadata. So let's go with the simpler VOPRF protocol instead! Test vectors generated from the code here: URL cc NAME NAME NAME
LGTM
Change:
flows and completely fail in the near future, and is therefore not recommended.  In addition, due to the speed of evolution of the protocol, devices that attempt to distinguish QUIC traffic from non- <del> QUIC traffic for purposes of network admission control should admit all QUIC traffic regardless of version. </del> <ins> QUIC traffic for purposes of network admission control should not rely on the version number field.  Instead it is recommended to admit all QUIC traffic regardless of version in order to support continious version-based evolution and avoid unnecessary deployment delays. </ins> 3.

Discussion:
lgtm
IMO the PR is clearer (and better reflects the intent / my understanding of WG consensus), so I'd merge it then continue the discussion after the submission cutoff.
Change:
1.2. <ins> A fragment identifier starting with "*" is to be interpreted as a YAML alias node fragment-alias-node. A fragment identifier that is empty or that starts with "/" is to be interpreted as a JSON Pointer JSON-POINTER and is evaluated on the YAML representation graph, walking through alias nodes; this syntax can only reference YAML nodes that are on a path that is made up of nodes interoperable with the JSON data model (see int-yaml-and-json). A fragment identifier is not guaranteed to reference an existing node.  Therefore, applications SHOULD define how an unresolved alias node ought to be handled. 1.2.1. </ins> This section describes how to use alias nodes (see Section 3.2.2.2 and 7.1 of YAML) as fragment identifiers to designate nodes.

Discussion:
includes clarification on JSON Pointer and alias nodes compatibility includes FAQ fragment identifier moved from media type to section empty fragment + are both under JSON Pointer
cc: NAME NAME PTAL
According to NAME this PR should better clarify JSON Pointer use, so I am going to merge it. The decision on forcing +yaml fragment is deferred to that I will rebase.
Change:
provide application programming interfaces by which clients and servers may request and verify exported authenticator messages. <ins> Notwithstanding the success cases described below, all APIs MUST fail if: the connection uses a TLS version of 1.1 or earlier, or the connection is TLS 1.2 and the extended master secret RFC7627 was not used </ins> Given an established connection, the application SHOULD be able to call the following APIs:

Discussion:
Relaying feedback received: We currently require EMS+TLS 1.2 or TLS 1.3+ in order for the Exported Authenticator API to be validly used. However, the definition of the APIs don't explicitly call out a failure path. We should probably address this. Simplest option would be to add a sentence to the description of each API that it fails if those conditions aren't met.
Change:
4.1. Each authenticator is computed using a Handshake Context and Finished <del> 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 1.3).  These values use different labels depending on the role of the sender: </del> <ins> MAC Key derived from the TLS connection.  These values are derived using an exporter as described in RFC5705 (for TLS 1.2) or TLS13 (for TLS 1.3).  These values use different labels depending on the role of the sender: </ins> The Handshake Context is an exporter value that is derived using the label "EXPORTER-client authenticator handshake context" or

Discussion:
NAME are you happy with the adjusted text? I don't consider DTLS support to be a big change since the only thing we are relying on from TLS is the exporter interface.
I think that this is sneaking in a big change with the DTLS thing. I'll try to find the email...
Change:
When an SRTP or SRTCP packet contains a ShortEKTField, the ShortEKTField is removed from the packet then normal SRTP or SRTCP processing occurs.  If the packet contains a FullEKTField, then <del> processing continues as described below. </del> <ins> processing continues as described below.  The reason for using the last byte of the packet to indicate the type is that the length of the SRTP or SRTCP part is not known until the decryption has occurred.  At this point in the processing, there is no easy way to know where the EKT field would start.  However, the whole UDP packet has been received so instead of the starting at the front of the packet, the parsing works backwards off the end of the packet and thus the type is put at the very end of the packet. </ins> The Security Parameter Index (SPI) field is used to find which EKT parameter set to be used when processing the packet.  If there is

Discussion:
Does this way of phrasing it look better ?
2) s2.2.2, : I gotta ask why the MessageType byte isn’t first? Wouldn’t putting the MessageType first allow you avoid buffering everything before proceeding? It seems like you’re counting on nobody sending a string of zeros as the first byte of the EKT field to mess with implementations.
Change:
number of TCP segments is not guaranteed to map predictably to the size and number of HTTP DATA or QUIC STREAM frames. <ins> Once the CONNECT method has completed, only DATA frames are permitted to be sent on the stream.  Extension frames MAY be used if specifically permitted by the definition of the extension.  Receipt of any other frame type MUST be treated as a connection error of type HTTP_UNEXPECTED_FRAME. </ins> The TCP connection can be closed by either peer.  When the client ends the request stream (that is, the receive stream at the proxy enters the "Data Recvd" state), the proxy will set the FIN bit on its

Discussion:
This still seems like a pointless restriction to me, but it's what we agreed in Tokyo, so here it is.
NAME I think I share the concern (though I am not sure how much I care). HTTP/3 is expected to allow extension frames to be used without coordination; this PR forbids that to happen on a stream that uses the CONNECT method.
S 5.2. Can you send anything other than DATA on a CONNECT stream? You don't say that I can't send anything else, but you don't say I can't either.
It doesn't mean anything (because we haven't assigned semantics), but we should probably just forbid the use of other frames (of those defined in this document). This is probably a shortcoming of 7540 as well.
Wouldn’t it be better to just prohibit the HEADERS frame? We might want to introduce a frame that changes a property of a stream (e.g., max bitrate). I do not think there’s a strong reason to forbid such kind of extensions only on CONNECT stream.
I don't want to prohibit extension frames, but the frames defined in the current spec don't serve any purpose. That is why I said "of those defined in this document".
Well, there's technically nothing preventing the use of push.... ;-) More seriously, I don't feel like the prohibition adds much. This maps the definition of the CONNECT method into H3 framing -- DATA frames == TCP payload. In any other respect, it's an HTTP request and frames mean what they otherwise mean. Is there a particular frame that needs to be prohibited? HEADERS would indicate a trailer block; it might be worth upstreaming to the updated semantic draft that a CONNECT tunnel can't have trailers.
Discussed in Tokyo; after the CONNECT takes effect, all frames other than DATA are prohibited unless an extension specifically provides otherwise.
nits
Change:
Hash algorithm on the connection where the ticket was established. For externally established PSKs, the Hash algorithm MUST be set when the PSK is established, or default to SHA-256 if no such algorithm is <del> defined.  The server must ensure that it selects a compatible PSK (if </del> <ins> defined.  The server MUST ensure that it selects a compatible PSK (if </ins> any) and cipher suite. <ins> Each PSK is also associated with at most one Server Name Identification (SNI) value (Section 3 of RFC6066).  For PSKs established via the ticket mechanism (NSTMessage), this is the SNI value (if any) on the connection where the ticket was established. For externally established PSKs, the associated SNI value (or lack of value) is set when the PSK is established.  The server MUST ensure that it selects a compatible PSK (if any) and SNI value (if any). SNI MUST NOT be negotiated when using a PSK not associated with an SNI value. </ins> Implementor's note: the most straightforward way to implement the PSK/cipher suite matching requirements is to negotiate the cipher suite first and then exclude any incompatible PSKs.  Any unknown PSKs

Discussion:
Both for 0-RTT and 1-RTT. Give NST- and externally-provisioned PSKs more uniform treatment.
NAME ping? It would be good to get some resolution in this space, as it's somewhat relevant to URL
I guess we could perhaps recommend that external PSKs not be provisioned with a SNI value, since the PSK value itself ought to serve as enough of a lookup key for what the intended communication semantics are.
NAME is there a path forward for this (e.g., does it need to go to the list)?
NAME I think this is generally good except for the SNI stuff which conflicts with PR , which we also need to resolve one way or another. What say we land this without those pieces and then when we we will know what to do
SGTM. Do you need me to adjust the patch?
Nah, I'll do it.
These actually just seem to make the SNI requirements clearer but no sharper, so merging.
The Early Data Indication section contains this sentence: The parameters for the 0-RTT data (symmetric cipher suite, ALPN protocol, etc.) are the same as those which were negotiated in the connection which established the PSK. This implies to me that you can only do 0-RTT where the PSK was established via an earlier connection. In external PSK this is not the case. I don't think this interpretation was the intention.
This is stale text from before we allowed 0-RTT with external PSK, IIRC.
Zero-RTT Data says: But 4.6.1. New Session Ticket Message says: For consistency, I would like to have the latter in Section 2.2 with the same style. Moreover, I would like to know where this differences of requirements come from.
I think 4.2.10 may be more appropriate than 2.2, as it is closer to where the server is doing the relevant processing.
Now 4.2.10 has clear requirements. So, why don't we remove the same requirement from 2.3? additional information MUST be provisioned to both parties:
Change:
the AS.  Established keying material between the AS and the RS allows the AS to apply cryptographic protection to the access token to ensure that its content cannot be modified, and if needed, that the <del> content is confidentiality protected. </del> <ins> content is confidentiality protected.  Confidentiality protection of the access token content would be provided on top of confidentiality protection via a communication security protocol. </ins> The keying material necessary for establishing communication security between C and RS is dynamically established as part of the protocol

Discussion:
This terminology decision was made in early days of OAuth = long time ago. Done. Done. Changed. I added a note that this confidentiality protection of the access token happens on top of the protection offered by the underlying communication security protocol. Text added. >-- Section 5 -- Text changed. >-- Section 5.1.1 -- >Could the word "unprotected" be better defined in "received on an unprotected channel" ? E.g., is it only about TLS ? Else, I like the implicit lack of trust. Text changed to "unsecured channel" >-- Section 5.1.2 -- I assume you mean "Section 5.3". Text added. >-- Section 5.5 -- >In "Since it requires the use of a user agent (i.e., browser)" is it "i.e." or "e.g." ? I cannot find this text in the document. >-- Section 5.6 -- OK OK. >-- Section 5.6.4.1 -- >In figure 11, would you mind adding the section ID in addition to RFC 6749 ? I failed to spot them in RFC 6749. Done. >-- Section 5.7.2 -- >It is a little unclear to me which profile must be used as 'profile' is optionnial? Should a default or any profile be used ? I cannot find this text. >-- Section 5.8.1 -- >Suggest to use the BCP14 "SHOULD" in the text "The default name of this endpoint in an url-path is '/authz-info'" Changed. >-- Section 10.2 -- >Is RFC 7049 really an informative reference as CBOR appears as the default encoding ? Changed to a normative reference and updated reference. All nits below have been addressed.
Comments addressed in this PR: URL
Merged
Change:
10.5. <del> The enhanced voucher-request described in section voucher-request- prm-yang is bases on RFC8995, but uses a different encoding based on I-D.ietf-anima-jws-voucher.  Therefore similar considerations as described in RFC8995 section 11.7 (Security Considerations) apply. The YANG module specified in this document defines the schema for data that is subsequently encapsulated by a JOSE signed-data Content- type as described in I-D.ietf-anima-jws-voucher.  As such, all of the YANG-modeled data is protected against modification.  The use of YANG to define data structures via the "yang-data" statement, is relatively new and distinct from the traditional use of YANG to define an API accessed by network management protocols such as NETCONF RFC6241 and RESTCONF RFC8040.  For this reason these </del> <ins> The enhanced voucher-request described in RFC8366bis is based on RFC8995, but uses a different encoding based on I-D.ietf-anima-jws- voucher.  The security considerations as described in RFC8995 section 11.7 (Security Considerations) apply. The YANG module specified in RFC8366bis defines the schema for data that is subsequently encapsulated by a JOSE signed-data Content-type as described in I-D.ietf-anima-jws-voucher.  As such, all of the YANG-modeled data is protected against modification. The use of YANG to define data structures via the RFC8971 "structure" statement, is relatively new and distinct from the traditional use of YANG to define an API accessed by network management protocols such as NETCONF RFC6241 and RESTCONF RFC8040.  For this reason these </ins> guidelines do not follow the template described by RFC8407 section 3.7 (Security Considerations Section).

Discussion:
move YANG to RFC8366bis
Some corrections are necessary regarding the referenced fields defined. BRSKI-PRM specifies the agent-provided-registrar-certificate in contrast to the registar-proximity-certificate. Will be addressed in the next commit.
Change:
Note: This is an update to TLS 1.2 so in practice many TLS 1.2 clients and servers will not behave as specified above. <del> Note: Versions of TLS prior to TLS 1.3 used the top 32 bits of the Random value to encode the time since the UNIX epoch.  The sentinel value above was selected to avoid conflicting with any valid TLS 1.2 Random value and to have a low (2^{-64}) probability of colliding with randomly selected Random values. </del> 6.3.1.3. When this message will be sent:

Discussion:
The sentinel value was chosen to avoid conflicting with any valid TLS 1.2 value, but this is not actually desirable. We need to avoid conflicting with any non-TLS-1.3 server but still be a valid TLS 1.2 value. A TLS 1.3 server must still correctly implement TLS 1.2 to interoperate with existing TLS 1.2 clients. In particular, placing it at the front clobbers TLS 1.2's server timestamp. Putting this in the random was silly and 1.3 rightfully removes it, but some software depends on servers sending a timestamp. The tlsdate program uses this as a secure-ish time synchronization protocol. Silly as it is, it exists and it arguably was following the letter of the TLS 1.2 spec, even if we don't like that timestamp very much... Move the sentinel to the end so servers may implement this downgrade protection (which will be needed in the short term given the current version negotiation as it forces browsers to implement the version fallback again) without breaking any tlsdate instances which may still exist.
Change:
The cTLS ClientHello is defined as follows. <del> 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. </del> <ins> The "profile_id" field MUST identify the profile that is in use.  A zero-length ID corresponds to the cTLS default protocol. </ins> 3.2.

Discussion:
This change also reserves short profile IDs for "well-known" use. Fixes URL
Can we please try to resolve this question soon to unblock implementation?
NAME NAME Any objection to merging this?
The template says it's an integer (in what range?), but the ClientHello says it's 0-255 bytes. I think it's probably easiest to say it's a string of 0-255 bytes, with the empty string reserved to mean "no template". I guess if you want to get fancy you could reserve all 1-4 byte strings.
Agreed. If you want to send a PR, I wouldn't object.
This LGTM.
Change:
6. <del> This memo includes no request to IANA. </del> <ins> The glossary of this memo extends the glossary of the taxonomy document RFC8406 as follows: ACM : Adaptive Coding and Modulation; BBFRAME: Base-Band FRAME - satellite communication layer 2 encapsulation work as follows: (1) each layer 3 packet is encapsulated with a Generic Stream Encapsulation (GSE) mechanism, (2) GSE packets are gathered to create BBFRAMEs, (3) BBFRAMEs contain information related to how they have to be modulated (4) BBFRAMEs are forwarded to the physical-layer; CPE: Customer Premises Equipment; COM: COMmunication; DSL: Digital Subscriber Line; DTN: Delay/Disruption Tolerant Network; DVB: Digital Video Broadcasting; E2E: End-to-end; ETSI: European Telecommunications Standards Institute; FEC: Forward Error Correction; FLUTE: File Delivery over Unidirectional Transport; IntraF: Intra-Flow Coding; InterF: Inter-Flow Coding; IoT: Internet of Things; LTE: Long Term Evolution; MPC: Multi-Path Coding; NC: Network Coding; NFV: Network Function Virtualization; NORM: NACK-Oriented Reliable Multicast; PEP: Performance Enhancing Proxy RFC3135 - a typical PEP for satellite communications include compression, caching and TCP acceleration; PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME with additional information (e.g., related to synchronization); QEF: Quasi-Error-Free; QoE: Quality-of-Experience; QoS: Quality-of-Service; SAT: SATellite; SATCOM: generic term related to all kind of SATellite COMmunication systems; SPC: Single-Path Coding; VNF: Virtual Network Function. </ins> 7. <ins> This memo includes no request to IANA. 8. </ins> Security considerations are inherent to any access network, and in particular SATCOM systems.  The use of FEC or Network Coding in SATCOM also comes with risks (e.g., a single corrupted redundant

Discussion:
Shouldn't the 'This document is a product of' para be far earlier in the document? Should mention be made of a glossary at end, rather than putting the glossary at the front?
In PR : we have moved the glossary to the bottom of the document and moved the "This document is a product of" at the beginning of the introduction.
Change:
has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. <del> The designated expert RFC8126 only ensures that the specification is publicly available.  An Internet Draft that is posted and never </del> <ins> The role of the designature expert is described in [this-RFC]. The designated expert RFC8126 ensures that the specification is publicly available.  An Internet Draft that is posted and never </ins> published or a standard in another standards body, industry <del> consortium, university site, etc. suffices. </del> <ins> consortium, university site, etc. suffices.  The expert may provide more in depth reviews, but their approval should not be taken as an endorsement of the supported group. </ins> Despite the following behavior being misguided, experience has shown that some customers use the IANA registry as checklist against which

Discussion:
This change aligns the DE text and adds more info about what the DE does and doesn't do. It also capitalizes "Recommended" so that it's more clear that we're referring to the column. NAME PTAL
LGTM, thanks for unifying the DE language.
Change:
added to the handshake transcript.  Note that ACKs can still be sent in the same UDP datagram as handshake records. <del> %%% ACKs struct { uint64 record_numbers<0..2^16-1>; } ACK; </del> <ins> %%% ACKs struct { RecordNumber record_numbers<0..2^16-1>; } ACK; </ins> a list of the records containing handshake messages in the current flight which the endpoint has received, in numerically increasing

Discussion:
NAME NAME
Well, clients can recover by tearing down the connection and starting over.
Sure, sure. I think this was in the context of a "single" connection. Perhaps it's not that important to clarify?
I'll add text.
I think the only comment that's left to be addressed is this: Perhaps what's missing is precisely that clarifying statement. Namely, that clients which find themselves in such a situation cannot recover.