jiebi/CodeConvo huggingface dataset:
Change:
4. <del> Applications MUST adhere to the following requirements for external PSKs: Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH exchange for forward secrecy.  Low entropy PSKs, i.e., those derived from less than 128 bits of entropy, MUST be combined with a Password Authenticated Key Exchange (PAKE) mechanism. Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a server MUST use distinct PSKs when acting as the client from when it is acting as the server.  This prevents redirection attacks. Nodes SHOULD use external PSK importers I-D.ietf-tls-external-psk- importer when configuring PSKs for each pair of TLS client and server.  If a distinct importer is used for each pair, then this satisfies condition (2). Where possible the master PSK (that which is fed into the importer) SHOULD be deleted after the imported keys have been generated.  This protects an attacker from bootstrapping a compromise of one node into the ability to attack connections between any node; otherwise the attacker can recover the master key and then re-run the importer itself. 5. </del> PSK privacy properties are orthogonal to security properties described in sec-properties.  Traditionally, TLS does little to keep PSK identity information private.  For example, an adversary learns

Discussion:
explain how tls exporter helps with KDF and mitigating selfie attacks. added text on psk identity usage.
I left it empty for Owen (NAME He was planning to contribute some text on PSK collisions (between external PSKs and between external and internal PSKs).
I'll merge and will remove it for now. Owen can add it when he gets around to his PR.
LGTM pending one orphan section!
Change:
Verify that the "prior_epoch" field of the Handshake message is equal the "epoch" field of the current GroupState object. <del> Use the "operation" message to produce an updated GroupState object incorporating the proposed changes. </del> <ins> Use the "operation" message to produce an updated, provisional GroupState object incorporating the proposed changes. </ins> Look up the public key for slot index "signer_index" from the roster in the current GroupState object (before the update).

Discussion:
At the MLS interim, the major feedback regarding authentication was that it would be good practice to provide explicit key confirmation. This PR adds an explicit confirmation field to Handshake messages, containing a MAC over the proposed (updated) state of the group, together with the latest handshake message.
Reflecting on offline conversation here: This PR derives a new key, then calculates the MAC over both the HS message and the group state; that others verify. PR 72 derives a new key, then sends that to the others to verify they all got the same key. We assume that, as the key was derived from a tree with this group state, it must be correct. These appear to test basically the same property, but I probably prefer this PR unless we can formally verify that they have the same properties (or at least the relevant ones); in which case 72 is a little more efficient.
So one question would be under what circumstances would this verify something that won't be verified by failing AEAD on any associated messages that decrypt? Or is it more just that we've now decoupled updates and message sending, so without a failing AEAD we need this to confirm too?
Thanks, NAME Absolutely agree that this needs more discussion. I'll send a ping on the list shortly.
NAME To answer your question, yes, the idea here is to fail before you get to the AEAD stage. In the spec before this PR merged, group members that arrived at different states would have different keys, but they would never find out that was the case until there was an AEAD failure. With this PR (or ), a peer know that if processing of a Handshake message succeeds, then it has the same GroupState as the sender.
Agreed that we need further discussion with academics, and modelling of the properties, but this seems good to provisionally merge.
Change:
The reason that the TTL is the maximum time to live is that a cache operator might decide to shorten the time to live for operational purposes, such as if there is a policy to disallow TTL <del> values over a certain number.  Also, if a value is flushed from the cache when its value is still positive, the value effectively becomes zero.  Some servers are known to ignore the TTL on some RRsets (such as when the authoritative data has a very short TTL) even though this is against the advice in RFC 1035. </del> <ins> values over a certain number.  Some servers are known to ignore the TTL on some RRsets (such as when the authoritative data has a very short TTL) even though this is against the advice in RFC 1035.  An RRset can be flushed from the cache before the end of the TTL interval, at which point the value of the TTL becomes unknown because the RRset with which it was associated no longer exists. </ins> There is also the concept of a "default TTL" for a zone, which can be a configuration parameter in the server software.  This is

Discussion:
In the "TTL" section this appears: Also, if a value is flushed from the cache when its value is still positive, the value effectively becomes zero. (1) Doesn't make sense to flush a value. I think the intention was to say "if an RRSet is flushed..." (2) nitpick: "when its value is still positive" sounds like maybe it makes assumptions about the way that caches work. It sounds like the TTL is decremented and updated in the cache over time. Something like "URL the end of the TTL interval" may be better. (3) I'm not quite sure what "effectively becomes zero" means for data that has been flushed. If its flushed its gone or at least not usable again in the future.
Change:
matching client request which contains the Request-Tag that is being used for this Q-Block1 body. <ins> The token used in the response SHOULD be from the last received payload.  See code for further information. </ins> 4.13 (Request Entity Too Large) This Response Code can be returned under similar conditions to

Discussion:
find another name than Quick-Block
A poll is ongoing. Updated to Q-Block in -02, but open to change if we get more inputs
Change:
The true content type is inside the encryption envelope, as described below. <del> 5. </del> <ins> When CID is being used, the content to be sent is first wrapped along with the true content type and padding into a DTLSInnerPlaintext value prior to encryption.  The DTLSInnerPlaintext value is then encrypted. dtls-record12 illustrates the record format. This field contains the byte encoding of a handshake, an alert message, or the raw bytes of the application's data to send. The DTLSInnerPlaintext.type value contains the content type of the record.  This is the non-obfuscated (true) content type. An arbitrary-length run of zero-valued bytes may appear in the cleartext after the type field.  This provides an opportunity for senders to pad any DTLS record by a chosen amount as long as the total stays within record size limits.  See Section 5.4 of for RFC8446 more details.  (Note that TLSInnerPlaintext in that section refers to DTLSInnerPlaintext in this specification.) </ins> <del> When CID is being used, the DTLSCompressed value is first wrapped along with the true content type and padding into a DTLSWrappedCompressed value prior to encryption.  The DTLSWrappedCompressed value is then encrypted. </del> <ins> The outer opaque_type field of a DTLSCiphertext record is always set to the value 25 (tls12_cid).  The actual content type of the record is found in DTLSInnerPlaintext.type after decryption.  By encapsulating the true content type inside the encrypted payload the outer content type (special_type) can be used to signal the new record layer format containing the CID. </ins> <del> The value of DTLSCompressed.fragment </del> <ins> The DTLSCiphertext.version field describes the protocol being employed.  This document describes an extension to DTLS version 1.2. </ins> <del> The true content type. </del> <ins> The DTLSCiphertext.length field indicates the length (in bytes) of the following DTLSCiphertext.encrypted_record, which is the sum of the lengths of the content and the padding, plus one for the inner content type, plus any expansion added by the AEAD algorithm. </ins> <del> Padding, as defined in RFC8446. </del> <ins> The AEAD-encrypted form of the serialized DTLSInnerPlaintext structure. Other fields are defined in RFC 6347.  Note that this specification does not make use of the DTLSCompressed structure. </ins> In addition, the CID value is included in the MAC calculation for the DTLS record, as shown below.  The MAC algorithm described in

Discussion:
Trying to address URL but also trying to expand the description a bit for clarity.
According URL all records seems to use a . Does this include the ?
Does this PR provide an improvement help? URL
Yes, it clarifies it for me.
Change:
protocol suite is intended to enable all the applications that are described as required scenarios in the use cases document RFC7478. <del> Other efforts, for instance the W3C WEBRTC, Web Applications and Device API working groups, focus on making standardized APIs and interfaces available, within or alongside the HTML5 effort, for those functions; this memo concentrates on specifying the protocols and subprotocols that are needed to specify the interactions that happen across the network. </del> <ins> Other efforts, for instance the W3C Web Real-Time Communications, Web Applications Security, and Device and Sensor working groups, focus on making standardized APIs and interfaces available, within or alongside the HTML5 effort, for those functions.  This memo concentrates on specifying the protocols and subprotocols that are needed to specify the interactions over the network. </ins> This memo uses the term "WebRTC" (note the case used) to refer to the overall effort consisting of both IETF and W3C efforts.

Discussion:
Spencer had the following comment: This is a nit, but in this text, Other efforts, for instance the W3C WEBRTC, Web Applications and Device API working groups, focus on making standardized APIs and interfaces available, within or alongside the HTML5 effort, it would be nice to have the names here match what's on the W3C website. So, "Web Real-Time Communication", "Web Application Security", and "Device and Sensors", unless I'm guessing at the mapping wrong. It's also easy to read that text with "Web Applications and Device API" as a single working group, so using a comma after "Web Application Security" would be helpful.
LGTM with editorial
Change:
associate an ACME account with an existing account in a non-ACME system, such as a CA customer database. <del> To enable ACME account binding, a CA needs to provide the ACME client with a MAC key and a key identifier, using some mechanism outside of ACME.  The key identifier MUST be an ASCII string.  The MAC key SHOULD be provided in base64url-encoded form, to maximize compatibility between non-ACME provisioning systems and ACME clients. </del> <ins> To enable ACME account binding, the CA operating the ACME server needs to provide the ACME client with a MAC key and a key identifier, using some mechanism outside of ACME.  The key identifier MUST be an ASCII string.  The MAC key SHOULD be provided in base64url-encoded form, to maximize compatibility between non-ACME provisioning systems and ACME clients. </ins> The ACME client then computes a binding JWS to indicate the external account holder's approval of the ACME account key.  The payload of

Discussion:
A few editorial things that Dale found.
Editorial diffs only. Merging as-is. Thanks NAME !
:shipit:
Change:
7.1. Upon receiving an "encrypted_client_hello" extension, the client- <del> facing server MUST check that it is able to negotiate TLS 1.3 or greater.  If not, it MUST abort the connection with a "handshake_failure" alert. </del> <ins> facing server determines if it will accept ECH, prior to negotiating any other TLS parameters.  Note that successfully decrypting the extension will result in a new ClientHello to process, so even the client's TLS version preferences may have changed. </ins> The ClientECH value is said to match a known ECHConfig if there exists an ECHConfig that can be used to successfully decrypt

Discussion:
The version check on the outer ClientHello doesn't make much sense since, when ECH is accepted, the version is based on the inner ClientHello anyway. See URL I've left a TODO since it seems weird to have a client requirement like that be so load-bearing without a corresponding server check. Not sure where we should go there.
I like this change, but it might be worth resolving the TODO.
Removed the TODO in favor of some clarifying text on the client side.
Change:
"extension_data" contains information specific to the particular extension type. <del> The initial set of extensions is defined in a companion document TLSEXT.  The list of extension types is maintained by IANA as described in iana-considerations. </del> <ins> The initial set of extensions is defined in RFC6066.  The list of extension types is maintained by IANA as described in iana- considerations. </ins> An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello.  If a

Discussion:
The TLS 1.2 RFC cited WIP extension definitions at time of publish. Update current draft to point the final RFC 6066.
URL Fix merged. This should be closable now.
Change:
collector's public key as follows: where "pk" is the HPKE public key encoded by the collector's HPKE key <del> configuration, "task_id" is "AggregateShareReq.task_id" and "server_role" is the role of the server ("0x01" for the leader and "0x00" for the helper).  "agg_share" is the serialized "AggregateShare", and "batch_interval" is obtained from the "AggregateShareReq". </del> <ins> configuration and "task_id" is "AggregateShareReq.task_id". "agg_share" is the serialized "AggregateShare", and "batch_interval" is obtained from the "AggregateShareReq". </ins> This encryption prevents the leader from learning the actual result, as it only has its own share and not the helper's share, which is <del> encrypted for the collector.  The helper responds to the collector with HTTP status 200 OK and a body consisting of the following structure: "collector_hpke_config_id" is "collector_config.id" from the task parameters corresponding to "CollectReq.task_id". "enc" is the HPKE encapsulated key, used by the collector to decrypt the aggregate share. "payload" is an encrypted "AggregateShare". </del> <ins> encrypted for the collector.  The helper responds to the leader with HTTP status 200 OK and a body consisting of an "HpkeCiphertext" where "config_id" is set to the collector's HPKE config ID, "enc" is set to the encapsulated HPKE context "enc" and "ciphertext" is "encrypted_agg_share". </ins> The leader uses the helper's aggregate share response to respond to the collector's collect request (see pa-collect).

Discussion:
When constructing HPKE contexts, we now include both sender and recipient roles, and the application label also includes the PPM version. I used here because we recently submitted draft-01 of and so the next submitted draft, which would include this change, will be . I also backported the definition of struct HpkeCiphertext from the interop PR because it makes everything tidier and should be non-controversial we can get a head-start on bringing those changes into main.
Fixed, thank you! I also rewrote the relevant paragraph to acknowledge that there's two encrypted input shares and that the leader should examine the HPKE config ID of the one intended for itself. Further, I recall NAME pointing out to me that should this draft get adopted by the WG, we'll reset to something like , so is the more appropriate application label.
There's one more instance of that needs to be changed to . Otherwise, LGTM.
Change:
All of the challenges above have a binding between the account private key and the validation query made by the server, via the key <del> authorization.  The key authorization is signed by the account private key, reflects the corresponding public key, and is provided to the server in the validation response. </del> <ins> authorization.  The key authorization reflects the account public key, is provided to the server in the validation response over the validation channel and signed afterwards by the corresponding private key in the challenge response over the ACME channel. </ins> The association of challenges to identifiers is typically done by requiring the client to perform some action that only someone who

Discussion:
As pointed out to the list: There is this sentence in the security considerations (10.2 Integrity of Authorizations) that strikes me as extremely misleading: "All of the challenges above have a binding between the account private key and the validation query made by the server, via the key authorization. The key authorization is signed by the account private key, reflects the corresponding public key, and is provided to the server in the validation response." The key authorization itself does NOT contain the signature of the account's key. It gets though signed by the account's key later on in the challenge response (not the validation response) over the ACME channel (not the validation channel). What about saying that in the chronological order of events?
Change:
Provider (SP) as described in I-D.ietf-mls-architecture.  In particular, we assume the SP provides the following services: <del> A long-term identity key provider which allows clients to </del> <ins> A long-term signature key provider which allows clients to </ins> authenticate protocol messages in a group. A broadcast channel, for each group, which will relay a message to

Discussion:
The public key in a credential is introduced without a special name and the field in the BasicCredential is currently called public_key, which is not very expressive. A few paragraphs below, it is referenced as "Identity Key" or simply "Identity", which is a bit misleading, as Credentials are supposed to contain an additional "identity" which is not the key. I propose we clear up the terminology a bit here and refer to the public key contained in a Credential as "Signature Key".
Change:
256-bits, i.e., the hash algorithms SHA-1 and SHA-256/64 (SHA-256 truncated to 64-bits) SHALL NOT be supported for use in EDHOC except for certificate identification with x5t and c5t.  For security <del> considerations of SHA-1, see RFC6194. The EDHOC MAC length MUST be at least 8 bytes and the tag length of the EDHOC AEAD algorithm MUST be at least 64-bits.  Note that secp256k1 is only defined for use with ECDSA and not for ECDH.  Note that some COSE algorithms are marked as not recommended in the COSE IANA registry. </del> <ins> considerations of SHA-1, see RFC6194.  As EDHOC integrity protects the whole authentication credential, the choice of hash algorithm in x5t and c5t does not affect security and it is RECOMMENDED to use the same hash algorithm as in the cipher suite but with as much truncation as possible, i.e, when the EDHOC hash algorithm is SHA-256 it is RECOMMENDED to use SHA-256/64 in x5t and c5t.  The EDHOC MAC length MUST be at least 8 bytes and the tag length of the EDHOC AEAD algorithm MUST be at least 64-bits.  Note that secp256k1 is only defined for use with ECDSA and not for ECDH.  Note that some COSE algorithms are marked as not recommended in the COSE IANA registry. </ins> 8.4.

Discussion:
I added a recommendation as well. I think this can be merged.
Looks fine to me, merging
states Then has which is using -15 (SHA-256/64), not -16 (SHA-256) for the hash. How was this decision arrived at?
Thanks for the comment. The hash algorithm used in x5t is independent of the EDHOC cipher suite, that should probably be mentioned in the draft. I will make a PR with some text on this.I don't think there was any discussion on this, but SHA-256/64 feels like a natural choice. As EDHOC integrity protects the whole certificate the length of the hash does not have any security relevance, the hash is just used to find the certificate, not to prove it is the correct one. Using SHA-256 would increase overhead with 24 bytes per message without any benefits. An implementation supporting SHA-256 can easily support SHA-256/64 (as it is just a truncated SHA-256).
NAME Than I need to run an update on test vectors for p256 as I have switched to SHA256. I will make an update to use SHA256/64 and pull request
Yes, please do. Using SHA-256 in x5t is just a waste of 24 bytes in message2 and message3. We should maybe give some recommendations in the draft regarding this, but I think it is hard to give normative requirements as x5t is just one example and future COSE header parameters and EAD might use cryptographic algorithms. The algortithms in X.509 in another example on algorithms not controlled by the cipher suite, Somebody might use a cert with a P-521 authentication key where the CA used RSA-PSS to sign the certificate together with cipher suite 2/3. Maybe the draft should recommend the use of algorithms from the ciphersuite also in cose headers, EAD, X.509, CWT, etc. In the case of x5t the recommendation could be to use the same hash function but with as much truncation as possible.
Can we close this now?
Works for me - thanks.
Change:
with a signature over that nonce by one of the private keys requested by the server. <del> The string "proofOfPossession" </del> <ins> The string "proof-of-possession" </ins> The validation JWS

Discussion:
awesome thanks :+1:
Any reason for the inconsistent naming of the challenge types? Specifically vs Wouldn't it make sense to stick to dash delimited words? or just camelCase, not that it matter as long as its consistent. I would personally avoid camelcase in that context since there is already a lot acronyms.
Change:
constants-of-interest) for a new path, but the delay SHOULD NOT be considered an RTT sample. <del> Initial packets and Handshake packets could be never acknowledged, but they are removed from bytes in flight when the Initial and Handshake keys are discarded, as described below in discarding- packets.  When Initial or Handshake keys are discarded, the PTO and loss detection timers MUST be reset, because discarding keys indicates forward progress and the loss detection timer might have been set for a now discarded packet number space. </del> <ins> When the Initial keys and Handshake keys are discarded (discarding- packets), any Initial packets and Handshake packets can no longer be acknowledged, so they are removed from bytes in flight.  When Initial or Handshake keys are discarded, the PTO and loss detection timers MUST be reset, because discarding keys indicates forward progress and the loss detection timer might have been set for a now discarded packet number space. </ins> 6.2.2.1.

Discussion:
Addresses comments 2, 4, 7, 8, 9, and 11.
one tiny suggestion, but lgtm -- thanks for doing this!