jiebi/CodeConvo huggingface dataset:
Code change:
A Key Derivation Function (KDF) <del> A Derive-Public-Key function that produces a public key from a private key </del> <ins> A Derive-Key-Pair function that produces an asymmetric keypair from a node secret </ins> A ratchet tree is a left-balanced binary tree, in which each node contains up to three values:

Related discussion:
text: The point NAME raises about avoiding unnecessary operations is relevant here: If we're forking the hashes like this, then we can remove the hashing part from Derive-Key-Pair, so that it's really just a definition of how you convert from an octet string to a private key (and thus its public key).
I disagree, it is not for MLS to define the and functions for all asymmetric schemes possibly used in HPKE. In MLS we should have to do only what TreeKEM does, aka, 2 KDFs, one outputing the parent's secret, one outputing the KEM encryption key, and that's it. I am willing to accept defining here but this is already odd.
If it's not our job, whose is it? It's not HPKE's job, because they don't have a need to convert byte strings to private keys. Some document needs to define this conversion in order for MLS to be implementable.
I agree we are in trouble here :) But I still wish that if we can avoid it, we should.
I agree that the KEM schemes themselves should define these things, like Curve25519 does. But it's like two lines of text. I'm not too bothered with it.
I think I'm a bit lost here. How do we go forward? Regarding the use of an abstract KDF: I was mostly just adapting the existing text, which used an abstract hash function if I recall correctly. I didn't touch the texts that got more concrete because they seemed to be a little outdated anyway. That shouldn't be a problem though.
NAME Ok, looking at this now, I am not sure what we decided in the end. I would be ok to define as you said but as it is KEM specific so there is no good solution for P256 or for whatever PQ KEM that would have a specific way of generating keys from pseudo random bytes...
NAME any suggestion here
Fixed by
Code change:
certificate directly instead of relying on a referential mechanism such as communicating only a hash and/or URL for the certificate. <del> Any security association protocol MUST use PFS (such as profiles providing PFS). </del> <ins> Any security association protocol MUST provide Forward Secrecy (whether inherently or as part of a profile of the security association protocol). </ins> The degree of security required on every hop of an ACP network needs to be consistent across the network so that there is no designated

Related discussion:
text: During IETF 106 I solicited some feedback on the ACP IPsec/IKEv2 usage from Valery Smyslov; I've tried to digest that feedback into new text here. Some aspects are still subject to change. I also made a minor tweak to the DTLS section to bring it into parity with the IPsec one.
Merging first, then fixing.
Code change:
The use of ALPN in the TLS and QUIC handshakes establishes the target application protocol before application-layer bytes are processed. <del> Because all QUIC packets are encrypted, it is difficult for an attacker to control the plaintext bytes of an HTTP/3 connection, which could be used in a cross-protocol attack on a plaintext protocol. </del> <ins> This ensures that endpoints have strong assurances that peers are using the same protocol. This does not guarantee protection from all cross-protocol attacks. Section 21.5 of QUIC-TRANSPORT describes some ways in which the plaintext of QUIC packets can be used to perform request forgery against endpoints that don't use authenticated transports. </ins> 10.3.

Related discussion:
text: Mostly because QUIC doesn't prevent all forms of request forgery. Thankfully, this is dealt with in detail in the transport draft.
NAME this looks good. Can you also change one sentence in Sec 1.2, from: to .
Hilarie Orman wrote: all this is assumed to be provided by QUIC. Section 10.2 says that all QUIC packets are encrypted; I'm not sure if that's true, or if QUIC has an option for "non-modifiable" without encryption.
Actually, we now know that this is not true, so this really needs to be fixed: -- from . The real solution here is to cite of the transport draft.
The version of QUIC required by this draft is always encrypted; that seems sufficient for the original issue. NAME issue is distinct, and worth fixing. I'll use this issue to track it.
... and we could add some text stating the integrity point in Section 1.2. NAME suggests: "comparable integrity and confidentiality to TLS over TCP"
Could we make some progress on this one?
Progress made; the PR now needs review.
Code change:
4.2.1. The ADDRESS_ASSIGN capsule allows an endpoint to inform its peer that <del> it has assigned an IP address to it.  It allows assigning a prefix which can contain multiple addresses.  This capsule uses a Capsule Type of 0xfff100.  Its value uses the following format: </del> <ins> it has assigned an IP address or prefix to it.  The ADDRESS_ASSIGN capsule allows assigning a prefix which can contain multiple addresses.  Any of these addresses can be used as the source address on IP packets originated by the receiver of this capsule.  This capsule uses a Capsule Type of 0xfff100.  Its value uses the following format: </ins> IP Version of this address assignment.  MUST be either 4 or 6.

Related discussion:
text: This change adds text that addresses conveyed by ADDRESSASSIGN can be used in the "source address" field of an IP packet, while addresses conveyed by ROUTEADVERTISEMENT can be used in the "destination address" field. While we're here, also add a small clarification when a prefix is assigned/advertised that any of these addresses can be used in the source/destination field, respectively. A future extension could create semantics for these addreses, but that is not called out in the text at this time.
I'm know I'm late looking at this but thanks as this small clarification is really helpful
The current text in this draft needs to be updated to match the changes from URL I'll write up a PR once existing conflicting PRs are merged.
NAME is this unblocked now?
We need to clearly state that ADDRESSASSIGN defines a set of addresses the receiver of the capsule can use as a source IP address on packets it generates We need to clearly state that ROUTEADVERTISEMENT defines a set of addresses the receiver of the capsule can use as a destination IP address on packets it generates Should we rename the capsules to make this relationship more clear in all use cases?
Let's bike shed the name here NAME NAME NAME
(to clarify Tommy's comment - if anyone comes up with a new name they like, they should post it here. If not, we'll go with advertisement and withdraw)
Thanks!
Code change:
5.5.3. <del> As many end devices have moved to wireless connectivity for the final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detection have emerged from radio interference and signal strength effects. </del> <ins> As many end devices have moved to wireless connections for the final hop (such as Wi-Fi, 5G, LTE, etc.), new problems in bandwidth detection have emerged. </ins> <del> Each of these technologies can experience sudden changes in capacity as the end user device moves from place to place and encounters new sources of interference.  Microwave ovens, for example, can cause a throughput degradation of more than a factor of 2 while active Micro. 5G and LTE likewise can easily see rate variation by a factor of 2 or more over a span of seconds as users move around. </del> <ins> In most real-world operating environments, wireless links can often experience sudden changes in capacity as the end user device moves from place to place or encounters new sources of interference. Microwave ovens, for example, can cause a throughput degradation in Wi-Fi of more than a factor of 2 while active Micro.  5G and LTE likewise can easily see rate variation by a factor of 2 or more over a span of seconds as users move around. </ins> These swings in actual transport capacity can result in user <del> experience issues that can be exacerbated by insufficiently responsive ABR algorithms. </del> <ins> experience issues when interacting with ABR algorithms that aren't tuned to handle the capacity variation gracefully. </ins> 5.6.

Related discussion:
text: Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section
Code change:
A client can use DNS over HTTPS as one of multiple mechanisms to obtain DNS data.  If a client of this protocol encounters an HTTP error after sending a DNS query, and then falls back to a different <del> DNS retrieval mechanism, doing so can weaken the privacy expected by the user of the client. </del> <ins> DNS retrieval mechanism, doing so can weaken the privacy and authenticity expected by the user of the client. </ins> 9.

Related discussion:
text: added authenticity
The potential for misunderstanding here is great. If we consider authenticity to be stated as a goal, we would need more explicit about the properties that this provides. Specifically, this does not provide authenticity with respect to responses, because that is the purpose of DNSSEC.
Yes, that is true. Thinking about it, I think a web application developer (one of the targets) reading this draft might not fully understand the differences between authenticity at the HTTP layer and authenticity at the DNS layer. One of the stated features of Secure Contexts is authenticated channels that guarantee data integrity. If possible, I think a few more sentences elaborating on this topic would not hurt.
I'm going to close this because we have no idea what kind of authentication that a user would expect, whereas we know pretty well what kind of privacy they expect.
I think there might be room for something different along these lines. DNS hijack from your configured DNS server is currently a major problem, and DoH does allow you to authenticate whether or not you are talking to your configured recursive (while not saying anything about e2e). I'm going to reopen to track..
Code change:
lookup clients may access the information. In this case, the endpoint (and not the lookup clients) needs to be <del> careful to check the RD's authorization. </del> <ins> careful to check the RD's authorization.  The RD needs to check any lookup client's authorization before revealing information directly (in resource lookup) or indirectly (when using it to satisfy a resource lookup search criterion). </ins> 7.4.

Related discussion:
text: Some small mainly editorial fixes from Ben's review, to be merged soon.
From Ben's updated ballot: Good point, queued up.
From Ben's updated ballot:: → "The RD (always, but especially here) then needs to verify any lookup client's authorization before reveling this information directly (in resource lookup) or indirectly (when using it to satisfy a resource lookup search criterion)"
From follow-up on Ben's initial DISCUSS: → "regular registrations (i.e., per {{registration}})"
From follow-up on Ben's initial DISCUSS: It'd sound like abuse of semicolons to me; keeping it open to ask RFC editor for their technical writing expertise.
Code change:
secrecy. If the adversary is active, the adversary can follow the protocol and <del> perform updates on behalf of the compromised party with no ability to an honest group to recover message secrecy.  However, MLS provides PCS against active adaptive attackers through its Remove group operation.  This means that, as long as other members of the group are honest, the protocol will guarantee message secrecy for all </del> <ins> perform updates on behalf of the compromised party with no ability for an honest group to recover message secrecy.  However, MLS provides PCS against active adaptive attackers through its Remove group operation.  This means that, as long as other members of the group are honest, the protocol will guarantee message secrecy for all </ins> messages exchanged in the epochs after the compromised party has been removed.

Related discussion:
text: For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.
Code change:
if the token is later transferred over an insecure connection (e.g. when it is sent to the authz-info endpoint). <del> Developers MUST ensure that the ephemeral credentials (i.e., the private key or the session key) are not leaked to third parties.  An adversary in possession of the ephemeral credentials bound to the access token will be able to impersonate the client.  Be aware that this is a real risk with many constrained environments, since adversaries can often easily get physical access to the devices and therefore use phyical extraction techniques to gain access to memory contents.  This risk can also be mitigated to some extent by making sure that keys are refreshed more frequently. </del> <ins> Care must by taken by developers to prevent leakage of the PoP credentials (i.e., the private key or the symmetric key).  An adversary in possession of the PoP credentials bound to the access token will be able to impersonate the client.  Be aware that this is a real risk with many constrained environments, since adversaries may get physical access to the devices and can therefore use phyical extraction techniques to gain access to memory contents.  This risk can be mitigated to some extent by making sure that keys are refreshed frequently, by using software isolation techniques and by using hardware security. </ins> 6.3.

Related discussion:
text: I removed the part about the DoS via AS Discovery hints since it was unrealistic.
I changed the text. Text added. Text added. Here is the text from Section 7.2 of draft-ietf-ace-dtls-authorize: URL All editorial comments addressed.
PR addressing comments can be found here: URL
Merged
Code change:
the "TLS Alerts" registry with value 52. IANA is requested to allocate two values in the "TLS Handshake Type" <del> registry, defined in TLS13, for RequestConnectionId (TBD), and NewConnectionId (TBD), as defined in this document.  The value for </del> <ins> registry, defined in TLS13, for request_connection_id (TBD), and new_connection_id (TBD), as defined in this document.  The value for </ins> the "DTLS-OK" columns are "Y". IANA is requested to add this RFC as a reference to the TLS Cipher

Related discussion:
text: As far as referring to the snake case in the main body, I went and looked at RFC 8446 and it does not refer to the snake case. I tend to think that if we make the change in 5.2 and A.2, that should be enough breadcrumbs for people to figure it out. I put them in the same order as they are in the registry and moved up newsessionticket. Triple check this change please.
This I-D registers two TLS HandshakeTypes. All of the other fields in the registry use snake_case.
Code change:
After a client receives a Retry packet, 0-RTT packets are likely to have been lost or discarded by the server.  A client SHOULD attempt to resend data in 0-RTT packets after it sends a new Initial packet. <del> A client MUST NOT reset the packet number it uses for 0-RTT packets, since the keys used to protect 0-RTT packets will not change as a result of responding to a Retry packet.  Sending packets with the same packet number in that case is likely to compromise the packet protection for all 0-RTT packets because the same key and nonce could be used to protect different content. </del> <ins> New packet numbers MUST be used for any new packets that are sent; as described in retry-continue, reusing packet numbers could compromise packet protection. </ins> A client only receives acknowledgments for its 0-RTT packets once the handshake is complete.  Consequently, a server might expect 0-RTT

Related discussion:
text: This moves text from the section on 0-RTT to the section on continuing after Retry. Though 0-RTT is the only thing that is seriously affected in the current design, Initial packets might also be affected if we ever wanted to protect those with anything other than a static key.
says that after receiving a Retry, clients MUST NOT reset the packet number for any packet number space, and references 17.2.3 for more info. However, 17.2.3 only explains why this is the case for 0-RTT packets. We should either narrow the prohibition or expand the explanation.
Or maybe move the explanation that currently exists 17.2.3 to 17.2.5.3 and use it as an example (to avoid it being read as the only reason).
NAME does NAME editorial change address your issue?
Yes, this is fine.
Code change:
where "node_public_key" is the public key of the node that the path secret is being encrypted for, group_context is the current <del> GroupContext object for the group, and the functions "SetupBaseI" and </del> <ins> GroupContext object for the group, and the functions "SetupBaseS" and </ins> "Seal" are defined according to I-D.irtf-cfrg-hpke. Decryption is performed in the corresponding way, using the private

Related discussion:
text: In the latest HPKE draft (draft-irtf-cfrg-hpke-04), "Initiator (I)" was renamed to "Sender (S)".
Code change:
The term "Remote Attestation" is a common expression and often associated or connoted with certain properties.  The term "Remote" in this context does not necessarily refer to a remote entity in the <del> scope of network topologies or the Internet.  It rather refers to a decoupled system or entities that exchange the payload of the </del> <ins> scope of network topologies or the Internet.  It rather refers to decoupled systems or entities that exchange the payload of the </ins> Conceptual Message type called Evidence I-D.ietf-rats-architecture. This conveyance can also be "Local", if the Verifier role is part of the same entity as the Attester role, e.g., separate system <del> components of the same Composite Device (a single RATS entity). Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf- rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device-attest. </del> <ins> components of the same Composite Device (a single RATS entity).  Even if an entity takes on two or more different roles, the functions they provide typically reside in isolated environments that are components of the same entity.  Examples of such isolated environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf-rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device- attest. </ins> 3.

Related discussion:
text: Comment > Here starts to talk about "additional requirements", but I wonder there is no other places in this draft talking about requirement, so what are the basic requirements? Regards & Thanks! Wei Pan
Code change:
The following values are used for L: <del> limits messages to 2^16 bytes in length.  The nonce length is 13 bytes allowing for 2^(13*8) possible values of the nonce without repeating. </del> <ins> limits messages to 2^16 bytes (64Kbyte) in length.  This sufficently long for messages in the constrainted world.  The nonce length is 13 bytes allowing for 2^(13*8) possible values of the nonce without repeating. </ins> limits messages to 2^64 byes in length.  The nonce length is 7 bytes allowing for 2^56 possible values of the nonce without

Related discussion:
text: Assign integer tags to the CCM modes that we are keeping. Remove the 192-bit key CCM modes from the table. Update example using CCM
Code change:
Mutual TLS certificate verification <del> OAuth Demonstration of Proof-of-Possession key proof header </del> HTTP Signing signature header OAuth PoP key proof authentication header

Related discussion:
text: remove OAuth DPoP binding. Described why on IETF mailing list: only works for asymmetric keys, requires key be presented in the header (duplicating information from GNAP messages). It was never meant to be a general purpose signing mechanism, though the FAPI group in OIDF is considering it as an option in current proposed work.
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: c380eb747945a8002c19de9784e86bee713951a0 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Ok that's weird (just removed some lines...), will have a look
Ok that was due to my rust analyser in vscode, fixed it now