jiebi/CodeConvo huggingface dataset:
Change:
new KeyShareEntry for the group indicated in the selected_group field of the triggering HelloRetryRequest. <ins> In a ServerHello message, the "extension_data" field of this extension contains a KeyShareServerHello value: %%% Key Exchange Messages struct { KeyShareEntry server_share; } KeyShareServerHello; A single KeyShareEntry value that is in the same group as one of the client's shares. </ins> If using (EC)DHE key establishment, servers offer exactly one KeyShareEntry in the ServerHello.  This value MUST be in the same group as the KeyShareEntry value offered by the client that the

Discussion:
I tend to narrow things from the right....
Programmer habits maybe, for me a "FooTest" is a specialization of "Test", so the current "KeyShareServerHello" looks like a specialization of "ServerHello" to me. It's a minor thing though.
Fair enough, but my habit is the opposite. :)
The text refers to helloretryrequest (e.g. in IANA considerations), but the HandshakeType enum refers to helloretryrequestRESERVED. Should something be said about Server Hello being able to modify ? Should something be said about rejecting handshake messages with ? (The current seems to suggest that the wire can really contain 6.)
My syntax validator also detects this error. We need to fix this.
I guess that it is hard to express a nested . So, it seems to me that a comment is reasonable:
That comment is not easy to parse for a machine :/ (btw, the comment is for the serverhello case, not clienthello). is only defined for enumerations, so we cannot do something like: (and even the above is not accurate since interpretation of random depends on the supportedextensions value.) Maybe something like: with the intention that ServerHelloParameters is populated while preparsing the SH message (prescan for supportedversions, detect HRR vs normal SH based on Random). This is inspired by the SecurityParameters type in RFC 5246.
LGTM. As a nitpick, maybe name it "ServerHelloKeyShare" instead of "KeyShareServerHello" (likewise for CH and HRR).
Change:
10. <del> Connections should remain open until they become idle for a pre- negotiated period of time.  A QUIC connection, once established, can be terminated in one of three ways: </del> <ins> An established QUIC connection can be terminated in one of three ways: </ins> idle timeout (idle-timeout)

Discussion:
NAME this is annoyingly close to done. Would you mind?
NAME : Take a look.
LGTM
Change:
function is a CBOR Sequence.  Note that H(TH_2, CIPHERTEXT_2) can be computed and cached already in the processing of message_2. <del> Compute MAC_3 = EDHOC-KDF( PRK_4x3m, TH_3, "MAC_3", ( ID_CRED_I, CRED_I, ? EAD_3 ), mac_length ).  If the Initiator authenticates with a static Diffie-Hellman key (method equals 2 or 3), then mac_length is the EDHOC MAC length given by the selected cipher suite.  If the Initiator authenticates with a signature key (method equals 0 or 1), then mac_length is equal to the output size of the EDHOC hash algorithm given by the selected cipher suite. </del> <ins> Compute MAC_3 = EDHOC-KDF( PRK_4x3m, TH_3, "MAC_3", << ID_CRED_I, CRED_I, ? EAD_3 >>, mac_length_3 ).  If the Initiator authenticates with a static Diffie-Hellman key (method equals 2 or 3), then mac_length_3 is the EDHOC MAC length given by the selected cipher suite.  If the Initiator authenticates with a signature key (method equals 0 or 1), then mac_length_3 is equal to the output size of the EDHOC hash algorithm given by the selected cipher suite. </ins> ID_CRED_I - identifier to facilitate retrieval of CRED_I, see

Discussion:
The new definition of info in th ecurrent specification is. I noticed two problems with this while implementing. To create the array you need to parse context to see how many items it contains. Unless context is validated, length is not strictly defined (an attacker could create collisions) I suggest that info is changed to:
In the exporter, the application using EDHOC could input a context (a encoded CBOR sequence) that is not valid CBOR. That is not a big problem, but might lead to security issues in the future, if is assumed that info is valid CBOR. URL prefered sequence to array. I don't think bstr wrapping the sequence has the same problems as array wrapping the sequence. Array wrapping the info sequence seems like an unesasary step. I suggest.
We have also gotten comments disliking the use of any
Current specification could give the impression that there is a single maclength. But the mac length in message2 and message_3 may be different.
One fix is to update to
Change:
path.  In both cases, the path is ordered from the leaf to the root; each node MUST be the parent of its predecessor. <ins> Note that in TreeKEM, the length of the "node_secrets" vector MUST be exactly one less than the length of the "nodes" vector, since the secret value for the leaf node is not encrypted.  For "i > 0", "node_secrets[i-1]" has the encrypted node secret corresponding to the public key in "nodes[i]". </ins> When using TreeKEM, the ECIESCiphertext values encoding the encrypted secret values are computed as follows:

Discussion:
This matches the behavior in TLS, and saves space (due to not having to send the nonce).
Merging based on r+ from NAME out of band
Change:
current maximum datagram size, referred to as PMTU probes.  All QUIC packets that are not sent in a PMTU probe SHOULD be sized to fit within the maximum datagram size to avoid the datagram being <del> fragmented or dropped RFC8085. </del> <ins> fragmented or dropped BCP145. </ins> If a QUIC endpoint determines that the PMTU between any pair of local and remote IP addresses cannot support the smallest allowed maximum

Discussion:
This includes all the updates to references in transport. This includes new code again. See URL It would be possible to cite BCP38 as an RFC and avoid this, but I think that the BCP reference is correct. Not as sure about the BCP145 reference, as we need to point to the RFC directly to get the section reference, but I think that is OK on balance.
Change:
Curve Diffie-Hellman (ECDH) exchange RFC7748.  In EAP-AKA' FS this exchange is run in an ephemeral manner, i.e., both sides generate temporary keys as specified in RFC7748.  This method is referred to <del> as ECDHE, where the last 'E' stands for Ephemeral. </del> <ins> as ECDHE, where the last 'E' stands for Ephemeral.  The two intially registered elliptic curves and their wire format is chosen to alging with the elliptic curves and formats specified for Subscription Concealed Identi er (SUCI) encryption in Appendix C.3.4 of 3GPP TS 33.501 </ins> The enhancements in the EAP-AKA' FS protocol are compatible with the signaling flow and other basic structures of both AKA and EAP-AKA'.

Discussion:
Not sure the attacks actually attacked the smart cards. Changed to "smart card supply chain" in the abstract and intro. This is very much related to zero trust principles. added a sentence about this. Any modern standard track EAP method should provide mandatory client identity protection. Copied the text from EAP-TLS 1.3 Motivation for the chosen curves is missing. Added link to the definition of SUCI encryption in appendix C.3.4. of TS 33.501 Added more text in security consideration on the attacks an attacker can do. Added more text in security consideration on frequent use of ECDHE.
Great! There's one typo but I'll fix it.
Change:
match a value provided in the corresponding "ECHConfig.cipher_suites" list. <del> Equal to "Expand(Extract("", config), "ech_config_digest", Nh)", where "config" is the "ECHConfig" structure and "Extract", "Expand", and "Nh" are as specified by the cipher suite KDF. (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.) </del> <ins> The configuration identifier, equal to "Expand(Extract("", config), "ech_config_id", Nh)", where "config" is the "ECHConfig" structure and "Extract", "Expand", and "Nh" are as specified by the cipher suite KDF.  (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.)  The length of this value SHOULD NOT be less than 16 bytes unless it is optional for an application; see optional-configs. </ins> The HPKE encapsulated key, used by servers to decrypt the corresponding "encrypted_ch" field.

Discussion:
Also, rename configdigest to configid to avoid confusion with cryptographic hash digests. cc NAME NAME NAME
It's bound by the size o the HPKE KDF output size, which is unlikely to be larger than 32B. Let's make this:
We should also add a requirement for the HPKE ciphersuite. E.g., 'Nh <= 2^8`.
(Careful with fenceposts: .) If config_digest is the output of a KDF, why could you not fix the length to something that is enough to avoid collisions (16 bytes seems ample for this) and not worry about Nh at all?
I think it makes sense to let the KDF dictate the security level, i.e., the collision probability of the config_digest.
I would argue that collision probability here doesn't contribute to security. If a config is misidentified, the result will be failure, not a reduction in security. A failure either because the group doesn't match or because peers end up disagreeing on keys.
True that it's an operational consideration rather than a security one. I still think it makes sense to let the length of be dictated by the KDF, since whether truncation is an operational risk depends on the KDF.
I assume here that a KDF is capable of producing uniform random bytes of arbitrary length, meaning that truncation isn't a factor. That's what is for, right?
That assumption holds if the input has sufficient entropy. Since the public key is public, there's no entropy from the point of view of an adversary who wants to distinguish the output from random.
(To be clear, I think truncating to something reasonable, like 16 bytes, is low risk. I would be fine with doing this.)
Change:
need to be active to allow for key rotation and server maintenance. privacy depends on having each configuration used by many other .  It <del> is critical prevent the use of unique configurations, which might be used to track of individual , but it is also important to avoid </del> <ins> is critical to prevent the use of unique configurations, which might be used to track of individual , but it is also important to avoid </ins> creating small groupings of that might weaken privacy protections. A specific method for a to acquire configurations is not included in

Discussion:
From NAME First and only time KeyConfig appear in the text. Section 6.7: Missing "to" after "used" Section 6.7: Remove the first "affected" Section 7: Missing "to" before prevent, remove "of"
Change:
Note that because of packet loss, it is possible for one side to be sending application data even though the other side has not received the first side's Finished message.  Implementations MUST either <del> discard or buffer all application data packets for the new epoch </del> <ins> discard or buffer all application data records for the new epoch </ins> until they have received the Finished message for that epoch. Implementations MAY treat receipt of application data with a new epoch prior to receipt of the corresponding Finished message as

Discussion:
NAME
I think that the older versions of the spec were good at using the term "datagram" to refer to the thing that holds DTLS records. This version now uses "packet" in a good number of places. Sometimes I think that it means "record", other times "datagram". I'm sure that this is just the influence of QUIC and it can be fixed easily.
Actually 6357 uses "packet" all over the place. I'll do an audit, but I'm not going to ones that mean IP packet.
Change:
expiration information as metadata alongside the token; See metadata for more discussion about metadata constraints.  Both techniques are equivalent since they cryptographically bind expiration to individual <del> tokens. Key rotations should be limited in frequency for similar reasons. See parametrization for guidelines on what frequency of key rotations are permitted. </del> <ins> tokens.  Key rotations should be limited in frequency for similar reasons. </ins> 3.2.3.

Discussion:
After quickly skimming the parameterization section, it became clear that we already discuss these things in various consideration sections throughout the document, so this was just redundant. Moreover, it's very use-case and deployment specific that once had value in the joint deployment model, so it doesn't seem like particularly helpful now that we've generalized things a bit. Removing and avoiding confusion seems like the best path forward.
I'll take this one to the list before merging.
The privacy calculations should be updated to take into account metadata more explicitly, and take into account the cost of the number of redemptions, rather than the global issuer count. If used in a multiple disjoint architecture ecosystem, then the math should also be taken in terms of a specific 'context' rather than treating the whole PrivacyPass ecosystem as a single global system (allowing for more nuanced requirements/limitations on issuer counts).
On reflection, we may be better off deleting the text entirely and making sure the justification for the parameterization is adequately covered in the security and privacy considerations elsewhere in the document.
Change:
Consolidate "ticket_early_data_info" and "early_data" into a single extension (*). <ins> Change end_of_early_data to be a handshake message (*). </ins> Remove spurious requirement to implement "pre_shared_key". Clarify location of "early_data" from server (it goes in EE, as

Discussion:
key changes happen at Handshake boundaries. Suggested by David Benjamin
I have one here, that could be a start: URL Also this is assuming PR URL is accepted ( becomes a message)
Merged.
Change:
is received (that is, from the "Data Recvd" state).  Similarly, it is possible for remaining stream data to arrive after receiving a RESET_STREAM frame (the "Reset Recvd" state).  An implementation is <del> free to manage this situation as it chooses.  Sending RESET_STREAM means that an endpoint cannot guarantee delivery of stream data; however there is no requirement that stream data not be delivered if a RESET_STREAM is received.  An implementation MAY interrupt delivery of stream data, discard any data that was not consumed, and signal the receipt of the RESET_STREAM immediately.  Alternatively, the RESET_STREAM signal might be suppressed or withheld if stream data is completely received and is buffered to be read by the application. In the latter case, the receiving part of the stream transitions from "Reset Recvd" to "Data Recvd". </del> <ins> free to manage this situation as it chooses. Sending RESET_STREAM means that an endpoint cannot guarantee delivery of stream data; however there is no requirement that stream data not be delivered if a RESET_STREAM is received.  An implementation MAY interrupt delivery of stream data, discard any data that was not consumed, and signal the receipt of the RESET_STREAM.  A RESET_STREAM signal might be suppressed or withheld if stream data is completely received and is buffered to be read by the application.  If the RESET_STREAM is suppressed, the receiving part of the stream remains in "Data Recvd". </ins> Once the application has been delivered the signal indicating that the stream was reset, the receiving part of the stream transitions to

Discussion:
For NAME
This is talking about the case of being in "Data Recvd" and therefore ignoring RESET_STREAM. Should the last sentence instead read: "In the latter case, the receiving part of the stream remains in "Data Recvd" ?
That sounds right.
Change:
defined in ARCHITECTURE. Unless otherwise specified, this document encodes protocol messages <del> in TLS notation from TLS13, Section 3.  Moreover, all constants are </del> <ins> in TLS notation from Section 3 of TLS13.  Moreover, all constants are </ins> in network byte order. 3.

Discussion:
This link is broken in a few ways. Note that the links has an trailing period in it, which is only part of the problem there; there is no Section 5.1.2 or Section "5.1.2.". Also, the function is called "BlindSign" in that version of the draft.
In the issuance protocol draft, there are a few places where it is assumed that a value will be a certain length, but no effort has been made to explicitly set a length. In : Is the 0x0002 two octets? Sure, you might readily assume that, but nothing says that explicitly. The same assumption appears in Sections 5.1 and 5.5.
Change:
provides the ability to detect reordering and drop.  However, the delay attack described above can't be thwarted in this manner. <ins> 12.4. As noted in trustmodel, Verifiers and Relying Parties have trust anchor stores that must be secured.  Specifically, a trust anchor store must resist modification against unauthorized insertion, deletion, and modification. If certificates are used as trust anchors, Verifiers and Relying Parties are also responsible for validating the entire certificate path up to the trust anchor, which includes checking for certificate revocation.  See Section 6 of RFC5280 for details. </ins> 13. This document does not require any actions by IANA.

Discussion:
Also add a brief security considerations section, based on text from the TEEP architecture draft. Signed-off-by: Dave Thaler
Does “trust anchor store” in Layered Attestation Environments require an introduction?
I advocate taking it out. See and . If / when "trust anchor store" is in the architecture document it should be in the establishment of trust in the basic non-layered Attester. It should be somewhere in section 7.
PR addresses the original issue but there is more needed than just what is in PR to fully address this in my view. Two pieces remain: 1) Currently the trust anchor store is mentioned in the Verifier but not the Relying Party, and appropriate language should be updated in the Relying Party section also. 2) Unlike the TEEP architecture, the Security Consideration section focuses on the attester and so does not mention securing the trust anchor store on the Verifier and Relying Party.
Having merged , the definition of trust-anchor store definition will get moved upwards so that it can be referenced in Relying Party section, and then also a SC paragraph about securing the store.
The last sentence of the abstract is: but "such" remote attestation procedures are not defined earlier.
Change:
MediaStreamTrack.  For the answerer, these mandatory constraints can be applied to the remote MediaStreamTracks that are created by a setRemoteDescription call, and will affect the output of the ensuing <del> createAnswer call.  For the offerer, since it does not know about any remote MediaStreamTracks until it receives theanswer, this implies that it can only set these constraints after the initial offer-answer exchange is complete, and as a result, a new offer-answer is needed to communicate them. </del> <ins> createAnswer call.  Any constraints set after setLocalDescription is used to set the answer will result in a new offer-answer exchange. For the offerer, because it does not know about any remote MediaStreamTracks until it receives the answer, the offer can only reflect decoder hard limits.  If the offerer wishes to set mandatory constraints on video resolution, it must do so after receiving the answer and the result will be a new offer-answer to communicate them. </ins> The resulting resolution space formed by intersecting the decoder hard limits with any mandatory constraints will be used as the x= and

Discussion:
LGTM - I think that makes it clear what can and can not work.
lgtm
Change:
3.2. By definition, the Attester role generates Evidence.  An Attester may <del> consist of one or more nested environments (layers).  The root layer of an Attester includes at least one root of trust.  In order to appraise Evidence generated by an Attester, the Verifier needs to trust the Attester's root of trust.  Trust in the Attester's root of trust can be established in various ways as discussed in verifier. In layered attestation, a root of trust is the initial Attesting Environment.  Claims can be collected from or about each layer.  The corresponding Claims can be structured in a nested fashion that reflects the nesting of the Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer.  Claims about a root of trust typically are asserted by an Endorser. </del> <ins> consist of one or more nested environments (layers).  The bottom layer of an Attester has an Attesting Environment that is typically designed to be immutable or difficult to modify by malicious code. In order to appraise Evidence generated by an Attester, the Verifier needs to trust various layers, including the bottom Attesting Environment.  Trust in the Attester's layers, including the bottom layer, can be established in various ways as discussed in verifier. In layered attestation, Claims can be collected from or about each layer beginning with an initial layer.  The corresponding Claims can be structured in a nested fashion that reflects the nesting of the Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer. Claims about an initial layer typically are asserted by an Endorser. </ins> The example device illustrated in layered includes (A) a BIOS stored in read-only memory, (B) a bootloader, and (C) an operating system

Discussion:
Reworded sections containing root of trust leaving a single parenthetical that associates the term loosely with an attesting environment that is implicitly trusted.
It makes sense to remove the term 'root of trust' since the document doesn't define it. It might make sense to reference other industry specs that have relevant definitions such as NISTIR 8320A.
NAME apparently, this taks has no assignees. Do you want to do that?
OK, assign it to me.