jiebi/CodeConvo huggingface dataset:
Code change:
GroupSecrets object with the "psks" field set, the receiving Client includes them in the key schedule in the order listed in the Commit, or in the "psks" field respectively.  For resumption PSKs, the PSK is <del> defined as the "resumption_secret" of the group and epoch specified in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: </del> <ins> defined as the "resumption_psk" of the group and epoch specified in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: </ins> Here "0" represents the all-zero vector of length "KDF.Nh".  The "index" field in "PSKLabel" corresponds to the index of the PSK in

Related discussion:
text: I mean something very specific: That the security guarantees of MLS will not be harmed if a public value is provided to the attacker, and they will be harmed if a secret value is provided to the attacker. Importantly, "public" does not mean that the value must be published, or that the security guarantees of an application using MLS will not be harmed if you publish the value. It seems to me that in that specific taxonomy, the is "public" and not "secret". Do you disagree?
BTW, the notion of something being "public" at one layer but "secret" at another is not new. For example, values exported from TLS aren't secret in the sense that publishing them would compromise TLS. You could authenticate your TLS connection by exporting a value and shouting it through megaphones across a crowd. But the main way people use them in practice is as secrets in some other protocol. Every WebRTC call uses SRTP keys that are exported from TLS, and many people would be very sad if these "public" values were published.
If it would help, I would be happy to add some text to the Security Considerations clarifying this distinction. Basically, draw a clear boundary around which values have to be kept confidential to the client in order to realize the security properties of the protocol. But I still think is a clearer name. Doesn't mean you have to use it in any particular way in your application; doesn't prevent it being used as a shared secret; but also doesn't imply that the MLS library has to worry about its secrecy.
Within the bounds of that particular taxonomy there is not an issue. However, while you may be following a given taxonomy, that is not a general one, one that would be widely understood by implementors, nor is it specified in the protocol spec. It is not an unreasonable taxonomy, but it certainly not a general one. If you are looking for MLS usage spec to align to your taxonomy then I do think that there should be a clarification section added. BTW as a point case on more standard terminology use, the TLS 1.3 spec uses the exact phrasing for exporters as "exportermastersecret", from which the actual exporter may be derived. This aligns very closely to the authenticationsecret, from which an authentication code later may be derived.
Code change:
GroupSecrets object with the "psks" field set, the receiving Client includes them in the key schedule in the order listed in the Commit, or in the "psks" field respectively.  For resumption PSKs, the PSK is <del> defined as the "resumption_secret" of the group and epoch specified in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: </del> <ins> defined as the "resumption_psk" of the group and epoch specified in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: </ins> Here "0" represents the all-zero vector of length "KDF.Nh".  The "index" field in "PSKLabel" corresponds to the index of the PSK in

Related discussion:
text: TLS is generic in 'exporters' after an exportermastersecret is derived. Thus there is alignment of the term 'secret' to things that can be used for keys (have sufficient entropy), not as an alignment to public/secret at different layers. I am strongly opposed to the use of authenticationcode, and see no clear definition for that in your customized taxonomy. As such, it would follow the more standard interpretations, such as message authentication codes, etc. which are indeed explicitly public values. Codes are normally an end-state in themselves, not keys. Perhaps it is a clearer name for the Cisco implementation design, but it is not a clear name for something that can/should be used for further derivations as may be more generally applicable. Following the TLS norm for exporters, the name would be "authenticationmastersecret". The shortened "authenticationsecret" was a good name. If you are going to provide a write-up for the custom taxonomy, then an adjustment to "authenticationexporter" could perhaps be made.
The notion of a having boundary to the protocol and values that may or may not safely be exported across the boundary is not exotic or customized. You see it in FIPS 140-2, PKCS, and WebCrypto, and in tools like ProVerif and Tamarin. The only choice I'm making is in the specific words, in particular reserving "secret" for "something that should not be exposed outside the protocol implementation because it would compromise the protocol". I hope you agree that is different from say in this regard. It would be OK for an MLS implementation to have an API for an application to access the , but it would not be OK to have an API to access the . I'm not wedded to , I just want something other than . If you want to align with the exported values (to which I agree it is similar), we could call it an .
The distinction between those documents and tools, and the MLS spec is that those tools clearly define the boundaries and terminology, vs. just anyone making terminology assumptions without them being specified in the document. Not to be pedantic, but if you want to assume specific meanings for terms relative to a threat model for MLS only, versus a general usage ("exporter secrets" being secrets used in other things), then you really do need to specify those assumptions within the specification itself and not various side discussions.
Code change:
GroupSecrets object with the "psks" field set, the receiving Client includes them in the key schedule in the order listed in the Commit, or in the "psks" field respectively.  For resumption PSKs, the PSK is <del> defined as the "resumption_secret" of the group and epoch specified in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: </del> <ins> defined as the "resumption_psk" of the group and epoch specified in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: </ins> Here "0" represents the all-zero vector of length "KDF.Nh".  The "index" field in "PSKLabel" corresponds to the index of the PSK in

Related discussion:
text: Such specification is part of what a standard is meant to do. Within other documents this is clearly defined - i.e., what is known as a threat model - such as one sees in ProVerif and Tamarin. Assuming that you are going to add such a taxonomy, and that it follows that described by you in , then the correct term would be "authenticationkey". To quote you what you said there, which correctly aligns to a reasonable usage of the authenticationkey. pointed out that there is a lack of consistency in the usage of "keys" vs "secrets" throughout the document - something that still has not been addressed and should not be dropped from the issue for edits. Regardless of what taxonomy is being used or even assumed, there is no consistency in it in the spec. You seem to be commenting on adjustments only for the "key" and "secret" uses that appear as variables, but the commentary within the spec interchangeably use these terms for the same thing. Whatever is used should be applied consistently. It is not reasonable to assume that developers will correctly guess reasons for terminology separations particularly when they are inconsistently enforced.
On your latter point about usage of "keys" vs "secrets" throughout the document — Sorry if I misinterpreted your intent here. If you're seeing places where there are inconsistencies, it would be helpful if you could highlight those more specifically, or ideally send a PR to fix them.
NAME had a call about this today and hashed out a couple of things: We should be clear in general about what we mean by secrets/keys, in that we generally use them interchangeably, but sometimes use one or the other to indicate how a specific value is used The need for secrecy of the value labeled depends on the context in which it is used. So we should provide some text to suggest that there are different ways to use it, and use a fairly neutral name. NAME suggested , which I like a lot. I have attempted to implement these in
The spec currently uses a mix of terminologies for keys/secrets.
Code change:
GroupSecrets object with the "psks" field set, the receiving Client includes them in the key schedule in the order listed in the Commit, or in the "psks" field respectively.  For resumption PSKs, the PSK is <del> defined as the "resumption_secret" of the group and epoch specified in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: </del> <ins> defined as the "resumption_psk" of the group and epoch specified in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: </ins> Here "0" represents the all-zero vector of length "KDF.Nh".  The "index" field in "PSKLabel" corresponds to the index of the PSK in

Related discussion:
text: In the key schedule we have the following: senderdatasecret | "sender data" encryptionsecret | "encryption" exportersecret | "exporter" authenticationsecret | "authentication" externalsecret | "external" confirmationkey | "confirm" membershipkey | "membership" resumptionsecret | "resumption" It would be best to provide a coherency to how we use these terms and check for consistency throughout, to avoid confusion for readers: A simple solution would be to use "secret" for all cases, i.e., changing membershipkey to membershipsecret.Another alternative, which may take more refining but could be useful to readers is to separate out terms based on items that are for internal protocol use versus external protocol use. For example, encryption, confirmation, membership, etc., would use "key" and exporter, authentication, etc., could use "secret", or vice versa. --Break-- Ref the mailinglist on confirmation vs authentication secrets, perhaps the naming of these two are a little misleading - authentication normally being within bounds of a protocol while confirmation is external to it. This confusion probably sparked some of that discussion to begin with. It could_ be worth considering switching those terms for clarity.
I actually think we have a fairly coherent taxonomy here: "secret" is something that gets fed into HKDF to derive further things "key" is something that gets fed into another algorithm, e.g., HMAC Looking through the list, the ones that deviate from this pattern are: , which is exported to the application but expected to be kept private , which is exported to the application but not expected to be kept private Given that, I would propose we update the table in question to something like the following, using because that's how it's used, and to follow the "security code" terminology used by applications:
Things are easier to understand like this! The "Purpose" column is quite valuable I think, I remember I was quite overwhelmed when I first read it and had no idea what all those secret / keys were used for. This helps to understand the big picture.
Code change:
An alternative is to rely on periodic email summaries of activity, such as those produced by a notification tool like github-notify-ml <del> [6].  This tool has been used effectively in several working groups, </del> <ins> [5].  This tool has been used effectively in several working groups, </ins> though it requires server infrastructure. A working group that uses GitHub MAY provide either facility at the

Related discussion:
text: I was tempted to remove the entire section on administrative policies, though left it as is. NAME what do you think?
Yeah, I figured it best to start small. Let me know if you need anything else before merging!
NAME Interesting that the circle CI build ran on the merge, but not the PR. I didn't see any build failures reported before it merged, but I just got the email reporting a missed reference. Maybe there are some tweaks you need to apply over there as owner of the org.
Yeah, I'll fix it. Thanks for letting me know!
I was thinking of being a little more aggressive about removing some of the text, with matching PRs for the other work, but this works.
Code change:
"signature_algorithms" is REQUIRED for certificate authentication. <del> "supported_groups" and "key_share" are REQUIRED for DHE or ECDHE key exchange. </del> <ins> "supported_groups" is REQUIRED for ClientHello messages using DHE or ECDHE key exchange. "key_share" is REQUIRED for DHE or ECDHE key exchange. </ins> "pre_shared_key" is REQUIRED for PSK key agreement.

Related discussion:
text: Even when (EC)DHE is in use, the "supported_groups" extension is only mandatory in the ClientHello; it can be omitted from the EncryptedExtensions, as per section 4.2.6. Given that, it is not MTI for the server sending to the client, but the client must be prepared to accept the extension in EncryptedExtensions (at least to the point of not crashing or aborting the handshake), so leave the MTI text unchanged. It would be too awkward to try to express this subtlety in such a concise list.
Code change:
Data whose semantics depends on the Capsule Type. <ins> Unless otherwise specified, all Capsule Types are defined as opaque to intermediaries.  Intermediaries MUST forward all received opaque CAPSULE frames in their unmodified entirety.  Intermediaries MUST NOT send any opaque CAPSULE frames other than the ones it is forwarding. All Capsule Types defined in this document are opaque, with the exception of the DATAGRAM Capsule, see datagram-capsule.  Definitions of new Capsule Types MAY specify that the newly introduced type is transparent.  Intermediaries MUST treat unknown Capsule Types as opaque. Intermediaries respect the order of opaque CAPSULE frames: if an intermediary receives two opaque CAPSULE frames in a given order, it MUST forward them in the same order. </ins> Endpoints which receive a Capsule with an unknown Capsule Type MUST <del> silently drop that Capsule.  Intermediaries MUST forward Capsules, even if they do not know the Capsule Type or cannot parse the Capsule Data. </del> <ins> silently drop that Capsule. Receipt of a CAPSULE HTTP/3 Frame on a stream that is not a client- initiated bidirectional stream MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. </ins> 4.1.

Related discussion:
text: NAME points out that in order to correctly forward DATAGRAMs between transports where the QUIC DATAGRAM frame isn't always available, intermediaries need the ability to parse some capsules.
CAPSULE was easier to understand when it was fully opaque. When should I choose to define a semi-opaque CAPSULE vs defining a new frame? Aren't both constructs effectively hop-by-hop?
NAME you're the one who asked for this :-) The benefit of a semi-opaque capsule is that it allows defining new capsules without having to update every single intermediary in the chain, because intermediaries forward all unknown capsules.
Code change:
be perceived as creating a conflict of interest for a particular MLS DE, that MLS DE SHOULD defer to the judgment of the other MLS DEs. <ins> 18.6. This document registers the "message/mls" MIME media type in order to allow other protocols (ex: HTTP RFC7540) to convey MLS messages. </ins> 19.  References 19.1.  URIs

Related discussion:
text: This is a minimal section for MIME type registration of message/mls. It assumes that PR include wire_format in all MLS messages (making a format parameter unnecessary), and that all messages have the MLS version number encoded (making a version parameter unnecessary). These parameters can be added if needed.
When MLS messages are transmitted over a protocol which supports Content-Type / MIME Type negotiation, signal that the message is an MLS message. Because MLS messages are really a bag of formats today we should have a MIME type parameter which specifies the specific format included. message/mls;format={applicationgroupcontext}
This seems like a fine idea to me. Could go as a section in the protocol spec, or as a separate (small) spec.
Discussion on virtual interim: Section or separate doc? How do we handle versioning? Internal to the protocol (field in MLSMessage?) Field in the MIME type Different MIME type per version
I would prefer a short section in the protocol document. I think Internal to the protocol is cleanest. Likewise the format parameter becomes unnecessary if we add Welcome, PublicGroupState, and KeyPackage to wire_format (see issue )
NAME send a PR?
Asking for friend: would we want to define (or use) a structured syntax suffix ala ?
NAME If you mean for multiple formats, no, we have only one encoding. If someone wants to re-encode the protocol as XML or whatever, a MIME type will be the least of their troubles.
Fixed in
Code change:
mpls and I-D.ietf-detnet-ip.  This draft does not have additional security considerations. <del> 5. </del> <ins> 7. </ins> This document makes no IANA requests.

Related discussion:
text: Based on 06.17 discussions. F-lables(s) added to Fig1 and text fixed. Adding procedures sections. Multiple notes added for clarifications. Adding controller plane section.
reviewed in Jun 24 meeting
Code change:
1. <del> The Internet does not always provide end to end reachability for native DNS.  On-path network devices may spoof DNS responses, block DNS requests, or just redirect DNS queries to different DNS servers that give less-than-honest answers.  These are also sometimes delivered with poor performance or reduced feature sets. Over time, there have been many proposals for using HTTP and HTTPS as a substrate for DNS queries and responses.  To date, none of those proposals have made it beyond early discussion, partially due to disagreement about what the appropriate formatting should be and partially because they did not follow HTTP best practices. </del> This document defines a specific protocol for sending DNS RFC1035 queries and getting DNS responses over HTTP RFC7540 using https:// (and therefore TLS RFC5246 security for integrity and

Related discussion:
text: This text is great justification to include in a charter, but this is a protocol specification and it really doesn't add much.
It seemed like the WG wanted the document to be shorter and more specific, so this feels good.
Code change:
Many application programming interfaces (APIs) to perform transport networking have been deployed, perhaps the most widely known and <del> imitated being the BSD socket() POSIX interface.  The naming of objects and functions across these APIs is not consistent, and varies </del> <ins> imitated being the BSD Socket POSIX interface.  The naming of objects and functions across these APIs is not consistent, and varies </ins> depending on the protocol being used.  For example, sending and receiving streams of data is conceptually the same for both an unencrypted Transmission Control Protocol (TCP) stream and operating on an encrypted Transport Layer Security (TLS) RFC8446 stream over <del> TCP, but applications cannot use the same socket send() and recv() calls on top of both kinds of connections.  Similarly, terminology for the implementation of transport protocols varies based on the context of the protocols themselves: terms such as "flow", "stream", "message", and "connection" can take on many different meanings. This variety can lead to confusion when trying to understand the similarities and differences between protocols, and how applications can use them effectively. </del> <ins> TCP, but applications cannot use the same socket "send()" and "recv()" calls on top of both kinds of connections.  Similarly, terminology for the implementation of transport protocols varies based on the context of the protocols themselves: terms such as "flow", "stream", "message", and "connection" can take on many different meanings.  This variety can lead to confusion when trying to understand the similarities and differences between protocols, and how applications can use them effectively. </ins> The goal of the Transport Services architecture is to provide a common, flexible, and reusable interface for transport protocols.  As

Related discussion:
text: A framer needs to support all possible outcomes of the transport services requested It may optimize based on the protocols it actually finds, e.g., turn into a no-op with the transport preserves message boundaries. Whether the next protocol is a sufficient representation of this is unclear to me. Maybe not, if one thinks of supporting arbitrarily large messages and UDP over IPv6 with and without fragmentation…
LGTM, thanks!
Code change:
Reasons for signing the zone by the HNA are: <del> 1) Keeping the Homenet Zone and the Public Homenet Zone equal to </del> <ins> Keeping the Homenet Zone and the Public Homenet Zone equal to </ins> securely optimize DNS resolution.  As the Public Zone is signed with DNSSEC, RRsets are authenticated, and thus DNS responses can be validated even though they are not provided by the

Related discussion:
text: …ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.
Code change:
This key is automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".) <ins> Support for the "port" key can be unsafe if the client has implicit elevated access to some network service (e.g. a local service that is inaccessible to remote parties) and that service uses a TCP-based protocol other than TLS.  A hostile DNS server might be able to manipulate this service by causing the client to send a specially crafted TLS SNI or session ticket that can be misparsed as a command or exploit.  To avoid such attacks, clients SHOULD NOT support the "port" key unless one of the following conditions applies: The client is being used with a DNS server that it trusts not attempt this attack. The client is being used in a context where implicit elevated access cannot apply. The client restricts the set of allowed TCP port values to exclude any ports where a confusion attack is likely to be possible (e.g. the "bad ports" list from the "Port blocking" section of FETCH). </ins> 4.3. These SvcParamKeys from SVCB apply to the "dns" scheme without

Related discussion:
text: Closes URL
Allowing the use of nonstandard port numbers in SVCB for DNS provides valuable operational flexibility, but it also creates a risk related to cross-protocol confusion attacks, in which a malicious server convinces a client to send TCP contents that can be misparsed as a different protocol by a non-TLS victim server. For example, a malicious DNS server could indicate an SNI or session ticket that can be misparsed as a command by a recipient server, and use DNS rebinding to change its own apparent IP address to the victim server. Clients would then send this server-controlled payload to the victim server. This is dangerous if the client is implicitly authorized to control the victim server (e.g. authorization by IP address). Note that only DoT and DoH (over TCP) are amenable to these attacks. QUIC Initial encryption ensures that the packet has no meaning to a recipient that is not QUIC-aware, and any QUIC-aware recipient should not be vulnerable to these attacks. We should consider ways to minimize the impact of these attacks. For example, we could require clients to restrict the value of the parameter to a small fixed list, or refer to the . Credit to NAME