jiebi/CodeConvo huggingface dataset:
Change:
"early_data" extension MUST produce a fatal "bad_record_mac" alert as per record-payload-protection. <del> [[TODO: How does the client behave if the indication is rejected.]] </del> <ins> If the server rejects the "early_data" extension, the client application MAY opt to retransmit the data once the handshake has been completed.  TLS stacks SHOULD not do this automatically and client applications MUST take care that the negotiated parameters are consistent with those it expected.  For example, if the ALPN value has changed, it is likely unsafe to retransmit the original application layer data. </ins> 4.2.7.1.

Discussion:
We currently have "identical" but Ilari argues we should have more specific rules
From Ilari: "Here is what I think should match (going through all currently known values and excetions): Version Ciphersuite Protection+PRF, key exchange in allowed values. What to do with servername??? Statusrequest presence (but not contents)??? Statusrequestv2 presence (but not contents)??? Signedcertificatetimestamp presence (but not contents)??? ALP can not be negotiated by any means. 0-RTT Protection+PRF+ALP can not be negotiated. (I think statusrequest and statusrequestv2 should mirror whatever signedcertificatetimestamp does). Also, that servername is just its own kind of mess, where what is the proper thing isn't at all obvious. And here is the list of extensions that are allowed to be negotiated with 0-RTT (parenthesis denotes extensions where things depend on exact handling discussed above). (servername) maxframgmentlength (statusrequest) supportedgroups usesrtp heartbeat (statusrequestv2) (signedcertificatetimestamp) tokenbinding [I-D stage] cachedinfo? keyshare presharedkey earlydata (required for obvious reasons) (Note: applicationlayerprotocol_negotiation is not on this list, very much intentionally, since negotiation of ALP is not possible in presence of 0-RTT. Don't even try)."
More from Ilari: Thinking about it some more, including statusrequest/statusrequestv2/ signedcertificatetimestamp is only useful if one wants to tie the ticket lifetime to parent certificate lifetime. Also, list of things saved for 0-RTT-capable context would be useful. I presume: The context name The PSK key The PSK context Timestamp Expiry time (not needed for 0-RTT) On server side: RTT estimate Allowed key exchanges Negotiated protection Negotiated PRF Negotiated ALP (negotiated via any means, or absence thereof) (Implementation-defined peer identity, not needed for 0-RTT) (Implementation-defined self identity, not needed for 0-RTT) What to do with servername??? (On server side, one can save the rest encrypted into context name).
Change:
Have any security considerations that are part of the message been enforced (as specified by the application or crit parameter)? <del> This document defines several algorithms where the computed authentication tag can be truncated to a shorter value than the default value.  Doing this truncation affects the authentication service provided by this value.  In general, [CREF3] </del> There are a large number of algorithms presented in this document that use nonce values.  For all of the nonces defined in this document, there is some type of restriction on the nonce being a

Discussion:
Started a birthday attack consideration, but it is not valid as far as I can tell so remove it.
Change:
Section 15.4. An "a=fingerprint" line for each of the endpoint's certificates, <del> as specified in RFC4572, Section 5; the digest algorithm used for </del> <ins> as specified in RFC8122, Section 5; the digest algorithm used for </ins> the fingerprint MUST match that used in the certificate signature. An "a=setup" line, as specified in RFC4145, Section 4, and

Discussion:
I don't know why build of ghpages is failing travis. It works for me on my machine so going to ignore this for a bit.
Here is the diff of the change.
BLOCKER: The nits tool reports (and a cursory hand check supports this) that six of the references are unused, and RFC4572 has been (recently) obsoleted. The remaining references are largely out of date by many versions, which I believe the current tools will automatically handle if version numbers are simply pulled out of the source. Finally, a large number of the referenced working group documents still use the individual name (e.g., draft-nandakumar-rtcweb-sdp instead of draft-ietf-rtcweb-sdp).
Need to verify section numbers when these refs change, but otherwise seems fine.
LGTMLG, assuming this generates the equivalent text.
Change:
Add missing entry to the TLS Alert Registry for the no_application_protocol alert defined in <ins> Added "Recommended" column to TLS ExtensionType Values, TLS Cipher Suite, and TLS Exporters Label registries.  Initial values marked "Yes" are specified in IETF Standards Track documents; all others are marked "No".  This new column is intened to alter the incorrect perception that getting a code point somehow legitimizes the extesion, cipher suite/algorithm, or exporter. </ins> This document proposes no changes to the registration policies for TLS Alert I-D.ietf-tls-tls13, TLS ContentType I-D.ietf-tls-tls13, TLS HandshakeType, I-D.ietf-tls-tls13 and TLS Certificate Status Types

Discussion:
Need to update summary to, at a minimum, reflect that the following is now in the draft: Added "Recommended" column to TLS ExtensionType Values, TLS Cipher Suite, and TLS Exporters registries to clearly indicate which values are specified in IETF Standards Track documents.
Change:
An authenticator message can be constructed by either the client or the server given an established TLS connection, a certificate, and a <del> corresponding private key.  For clients, an authenticator request is required; for servers an authenticator request is optional.  The authenticator uses the message structures from Section 4.4 of TLS13, but different parameters.  These messages do not include the TLS record layer and are therefore not encrypted with a handshake key. </del> <ins> corresponding private key.  Clients MUST NOT send an authenticator without a preceding authenticator request; for servers an authenticator request is optional. The authenticator uses the message structures from Section 4.4 of TLS13, but different parameters.  These messages do not include the TLS record layer and are therefore not encrypted with a handshake key. </ins> 4.1.

Discussion:
In Section 4, clients are required to have an authenticator request before generating and sending an authenticator. Later, in Section 4.2, the draft states that clients may get authenticator information from a SH or EncryptedExtensions in the event that no authenticator request is present. This seems to contradict the requirement in Section 4.
Change:
is a hostname that is used to identify the issuer that is allowed to issue tokens that can be redeemed by this origin. <del> "redemption_nonce" is an optional field.  If present, it indicates that a client needs to present an interactive token, generated specifically in response to this challenge.  If empty, the client can use a non-interactive token.  When present, this valid is a fresh 32-byte nonce generated by the origin for each challenge. Valid lengths for this field are either 0 or 32 bytes.  Challenges with redemption_nonce values of invalid lengths MUST be ignored. </del> <ins> "redemption_context" is an optional field.  If present, it allows the origin to require that clients fetch tokens bound to a specific context, as opposed to reusing tokens that were fetched for other contexts.  When present, this value is a 32-byte context generated by the origin.  This value can be a unique per-request nonce, or represent some state such as properties of the client session or current time window.  Valid lengths for this field are either 0 or 32 bytes.  Challenges with redemption_context values of invalid lengths MUST be ignored. </ins> "origin_name" is an optional string containing the name of the origin.  This allows a token to be scoped to a specific origin.

Discussion:
We should consider renaming to . This value doesn't need to be a nonce, it's just some origin-selected context that it is binding to. We can also rename the in the Token struct to to make it clear what role it has.
Change:
the cryptographic context. The same extension types MUST NOT appear in both the ServerHello and <del> EncryptedExtensions.  If the same extension appears in both locations, the client MUST rely only on the value in the EncryptedExtensions block.  All server-sent extensions other than those explicitly listed in server-hello or designated in the IANA registry MUST only appear in EncryptedExtensions.  Extensions which are designated to appear in ServerHello MUST NOT appear in </del> <ins> EncryptedExtensions.  All server-sent extensions other than those explicitly listed in server-hello or designated in the IANA registry MUST only appear in EncryptedExtensions.  Extensions which are designated to appear in ServerHello MUST NOT appear in </ins> EncryptedExtensions.  Clients MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST terminate the handshake with an "illegal_parameter" alert.

Discussion:
since server hello says that presence of extra extensions is a illegalparameter and encrypted extensions say that presence of server hello specific extensions is illegalparameter there is no reason to specify what to do with situation that MUST generate fatal alert
Change:
and fallback or re-establishment is supported in the transport system. <ins> The interface explicitly does not require the application to resolve names, though there is a tradeoff between early and late binding of addresses to names.  Early binding allows the API implementation to reduce connection setup latency, at the cost of potentially limited scope for alternate path discovery during Connection establishment, as well as potential additional information leakage about application interest when used with a resolution method (such as DNS without TLS) which does not protect query confidentiality. </ins> These communication activities are not different from what is used today.  However, the goal of a TAPS transport system is to support such mechanisms as a generic service within the transport layer.

Discussion:
I would reword this text in §5.1: such that the tradeoff is listed in a (new) privacy considerations section, leaving the description of the reduced connection setup latency in early binding here as a functional justification.
LGTM (note: accept 1 nit fix before pressing Merge)
Change:
An example set of protocol messages for this method can be found in example-device. <del> 1.5.3. </del> <ins> 1.5.4. </ins> In this example flow, the end user and RO roles are fulfilled by different parties, and the RO does not interact with the client

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: a48ba2e1204e2294f34f8550971f65f684ea7992 Inspect the deploy log: Browse the preview:
Sec. 1.5 (Sequences) would be clearer if we named the top sequence - all other sequences have been named. Maybe "main authorization flow"?
The sequences have not been names per say, they just happen to be related to a subtitle. We could of course create a new subsection, but the idea was to place this sequence above the others.
This is purely editorial. Naming it would make it easier to refer to this sequence.
Change:
4.4.2.2. <del> If the helper does not recognize the task ID, then it aborts preparation with HTTP status code 400 Bad Request and an error of type "unrecognizedTask". </del> <ins> If the helper does not recognize the task ID, then it MUST abort with error "unrecognizedTask". </ins> Otherwise, the helper continues with preparation for a report share by combining the leader's input message in "AggregateContinueReq" and

Discussion:
Addresses issue URL
I don't think that's true. : >DAP servers can return responses with an HTTP error response code (4XX or 5XX). For example, if the client submits a request using a method not allowed in this document, then the server MAY return HTTP status code 405 Method Not Allowed. So maybe we do need to specify that the status should be 400 (client error) and not 500 (server error). FWIW, has several places where it dictates HTTP 400 inline in the text, so I think it's OK for us to do that. I agree we should be consistent about using MUST throughout the document. Curiously, ACME has some examples where the 400 error response is a MUST, but the 200 success response has no all-caps applied to it. :
NAME NAME thanks for the comments, I've specified 400 in the errors section and shortened the words elsewhere.
Error types are either double quoted or code formatted, the text seems to encourage both: But these format are not consistent, some examples: It would be much clearer if we choose one style and make it consistent across the text.
The current protocol text doesn't specify what participants should do when a task ID is not recognized, there are two places unrecognized task are mentioned: In the table, it has: mentions "404 Not Found and an error of type unrecognizedTask", which seems to conflict with most implementation's choice of error code 400 (NAME ) The text should specify error 400 with type is used in every API that receives unrecognized task ID.
This would be useful I think. Would you mind sending a PR, NAME
NAME will do, create this issue to remind myself.
PR merged
Change:
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in the selected cipher suite, and the parameters defined <del> in asym-msg4-proc.  Discard padding, if present. </del> <ins> in asym-msg4-proc.  Discard the padding PAD_4, if present. </ins> Make (if present) EAD_4 available to the application for EAD processing.

Discussion:
This is an editorial change.
If there is a risk someone thinks that padding in the messages must be the same we could use PAD2, PAD3, PAD_4.
If I understand correctly, the PAD is to hide the length of the messages. If the three messages share the same PAD length, it is enough for one of the message to have a length known by the attacker, e.g. if EAD_4 is of constant length across all sessions, to leak the length of the PAD, and thus the length of the other messages contents. As such, 3 distinct padding lengths would be strictly better. Otherwise, as the encryptions are distinct (different key streams), I on my side don't see any weird cryptographic interactions that would be possible. (a side question is does the padding in message 2 leads to potential for padding oracles attacks, where the attacker could try to flip a few bytes of the cyphertext and learn some information based on which step of the processing fail. However, that is covered by I guess)
This is an editorial change. I merged the PR and will close this issue. No and yes. SIGMA and EDHOC and TLS 1.3 does not provide confidentiality of the second flight to active attackers (except maybe the signature). In SIGMA and EDHOC and attacker can modify the second flight and gain information. But this attack seems very uninteresting compared to attacks where the attacker modifies message_1.
Change:
blocks such packets) they may be encapsulated in UDP RFC3948 or TCP RFC8229. <del> 3.8.2. </del> <ins> 3.4.2. </ins> <del> 3.8.2.1. </del> <ins> 3.4.2.1. </ins> Encryption and authentication of handshake packets.

Discussion:
Sort the protocols we describe based on perceived importance, popularity, etc. Basically, put non-standard ones at the end, and all else towards the front.
Correct!
I'm assuming the content itself hasn't changed, just moved around? It's not obvious from the diff, so LMK if not and I'll un-approve.
Change:
provided by the server (see below).  Including this field indicates the client's agreement with the referenced terms. <del> A URI from which a list of authorizations submitted by this account can be fetched via a GET request.  The result of the GET request MUST be a JSON object whose "applications" field is an array of strings, where each string is the URI of an authorization belonging to this registration.  The server SHOULD include pending applications, and SHOULD NOT include applications that are invalid.  The server MAY return an incomplete list, along with a Link header with link relation "next" indicating a URL to retrieve further entries. </del> <ins> A URI from which an array of URIs for application objects submitted by this account can be fetched via a GET request. 6.1.2.1. Each registration object includes an applications URI from which a list of applications created by the registration can be fetched via GET request.  The result of the GET request MUST be a JSON object whose "applications" field is an array of URIs, each identifying an applications belonging to the registration.  The server SHOULD include pending applications, and SHOULD NOT include applications that are invalid in the array of URIs.  The server MAY return an incomplete list, along with a Link header with link relation "next" indicating a URL to retrieve further entries. </ins> 6.1.3.

Discussion:
In the "applications" field of the registration resource is described in great detail. This is confusing for two reasons: both the text and the example registration object are still using the "authorization" term that applications replace. the text is written as if the applications should be directly embedded in the registration object returned. This PR addresses both issues by describing the "applications" field as an array of application URIs that the client can fetch. The example "registration" object is updated accordingly. The note indicating a server SHOULD include pending applications and SHOULD NOT include invalid applications remains as-is. The note indicating a server MAY return an incomplete list is removed - it is more complicated and with only URIs being returned, likely an unneeded optimization. Finally, in there are three fields that must be ignored by the server in a registration body: key, authorizations and certificates. This should be "key" and "applications" and is updated accordingly.
NAME feedback addressed, and conflicts w/ master resolved. Thanks for the :eyes: !
Change:
Clients encapsulate a request "request" using values from a key configuration: <del> the key identifier from the configuration, "keyID", with the corresponding KEM identified by "kemID", </del> <ins> the key identifier from the configuration, "key_id", with the corresponding KEM identified by "kem_id", </ins> the public key from the configuration, "pkR", and <del> a selected combination of KDF, identified by "kdfID", and AEAD, identified by "aeadID". </del> <ins> a selected combination of KDF, identified by "kdf_id", and AEAD, identified by "aead_id". </ins> The client then constructs an Encapsulated Request, "enc_request", from a binary encoded HTTP request, "request", as follows: Construct a message header, "hdr", by concatenating the values of <del> "keyID", "kemID", "kdfID", and "aeadID", as one 8-bit integer and three 16-bit integers, respectively, each in network byte order. </del> <ins> "key_id", "kem_id", "kdf_id", and "aead_id", as one 8-bit integer and three 16-bit integers, respectively, each in network byte order. </ins> Build "info" by concatenating the ASCII-encoded string "message/ bhttp request", a zero byte, and the header.

Discussion:
RFC 9180 does use skR/pkR/skS/skR, so I didn't change everything to use snake_case, but this is more consistent with how we identify things in other places. Also, it reads better and we don't have to grapple with whether it should be keyId or keyID.
Change:
As a consequence of the expected deployment architecture, there is no basis for an application server to be known to a push service prior <del> to requesting delivery of a push message.  By the same measure, requesting the creation of a subscription for push message receipts has no prior authentication.  Requiring that the push service be able to authenticate application servers places an unwanted constraint on the interactions between user agents and application servers, who are the ultimate users of a push service.  That constraint would also degrade the privacy-preserving properties the protocol provides.  For these reasons, I-D.ietf-webpush-protocol does not define a mandatory system for authentication of application servers. </del> <ins> to requesting delivery of a push message.  Requiring that the push service be able to authenticate application servers places an unwanted constraint on the interactions between user agents and application servers, who are the ultimate users of a push service. That constraint would also degrade the privacy-preserving properties the protocol provides.  For these reasons, I-D.ietf-webpush-protocol does not define a mandatory system for authentication of application servers. </ins> An unfortunate consequence of this design is that a push service is exposed to a greater risk of denial of service attack.  While

Discussion:
This closes but does not completely address ?
You mean that I missed yes, I missed that on my first check. Let me know if you find anything else. (I haven't used the header field in the example to concentrate on the important bits.)
Introduction By the same measure, requesting the creation of a subscription for push message receipts has no prior authentication. In webpush-05, there is no longer an explicit request to create such a subscription. It's created implicitly as the result of requesting a push message delivery with receipts. Example In webpush-05, this changes to: and a reference to RFC7240 added.
Change:
QPACK defines two settings which are included in the HTTP/3 SETTINGS frame. <del> The default value is zero.  See _table-dynamic for usage.  This is the equivalent of the SETTINGS_HEADER_TABLE_SIZE from HTTP/2. </del> <ins> The default value is zero.  See header-table-dynamic for usage. This is the equivalent of the SETTINGS_HEADER_TABLE_SIZE from HTTP/2. </ins> The default value is zero.  See blocked-streams.

Discussion:
xml2rfc v3 format prohibits the use of these, which will cause problems. This makes the anchors longer, so feel free to go with something else.
Had to merge it, but feel free to fix anchors.
Change:
Abstract <del> This document describes a captive portal architecture.  DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described. </del> <ins> This document describes a captive portal architecture.  Network provisioning protocols such as DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described. </ins> 1.

Discussion:
Open up the abstract's wording a bit so we make it clear that other provisioning protocols could be used in the future for discovering the API URI.
Benjamin writes:
Change:
value to distinguish cTLS plaintext records from encrypted records, TLS/DTLS records, and other protocols using the same 5-tuple. <del> OPEN ISSUE: The profile_id is needed in the ClientHello to inform the server what compression profile to use.  For a ServerHello this field is not required.  Should we make this field optional? </del> Encrypted records use DTLS 1.3 RFC9147 record framing, comprising a configuration octet followed by optional connection ID, sequence number, and length fields.  The encryption process and additional

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.