jiebi/CodeConvo huggingface dataset:
Code change:
without accompanying evidence about its validity - used as proof of identity. <del> The Attester is issued with a credential by the Endorser that is randomised and then used to anonymously confirm the validity of their evidence.  The evidence is verified using the Endorser's public key. </del> _mandatory_ A statement representing an identifier list that MUST be

Related discussion:
text: 1) Can a DAA Issuer have multiple key pairs and use them for one Attester? 2) Can a DAA Issuer use one key pair to generate multiple credentials for one Attester? o A credential is conveyed from an Endorser to an Attester in combination with the conveyance of the public key certificates from Endorser to Verifier. Comment > Is there another way to convey the public key certificate, for example, can the public key certificates be conveyed from Endorser to Attester first and then from Attester to Verifier? The zero-knowledge proofs required cannot be created by an Attester alone - like the Endorsements of RoTs - and have to be created by a trustable third entity - like an Endorser. Due to that semantic overlap, the Endorser role is augmented via the definition of DAA duties as defined below. This augmentation enables the Endorser to convey trustable third party statements both to Verifier roles and Attester roles. Comment > For "the definition of DAA duties as defined below", what is the definition of DAA duties? Comment > In the last sentence, the Endorsement with its original definition is the third party statement for Verifier and Attester, isn't it? So, "augmentation" isn't the correct expression. Section 6 Normative Prerequisites Attester Identity: The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. Comment > The Attester Identity is to identify which Attester the Evidence comes from. But if the Attester has multiple Attesting Environments, what should be the Attester Identity? Comment > The TPM's AIK certificate is one kind of Attester Identity, right? Attestation Evidence Authenticity: Attestation Evidence MUST be correct and authentic. Comment > Is it appropriate to say "correct Evidence"? If saying so, I think it means that the Evidence satisfies the Attestation Policy for Evidence. Authentication Secret: An Authentication Secret MUST be available exclusively to an Attester's Attesting Environment. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence. The Authentication Secret MUST be established before RATS can take place. Comment > Does the Authentication Secret represent the identity of the Attesting Environment?
Code change:
without accompanying evidence about its validity - used as proof of identity. <del> The Attester is issued with a credential by the Endorser that is randomised and then used to anonymously confirm the validity of their evidence.  The evidence is verified using the Endorser's public key. </del> _mandatory_ A statement representing an identifier list that MUST be

Related discussion:
text: Comment > How to understand the Authentication Secret, and is it necessary all the time? For example, in our implementation, during the router booting up, the BIOS measures the BootLoader and records the measured hash value into the TPM, and the BootLoader measures the OS Kernel and records the measured hash value into the TPM as well. From the Layered Attestation perspective, I think (BIOS + TPM) is the Attesting Environment and (BootLoader + TPM) is also the Attesting Environment. But the Claims (measured hash values) aren't protected separately, and they finally becomes the Evidence (TPM Quote) and it's only protected by the TPM's AIK. So, what is the Authentication Secret? Section 7 Generic Information Elements Attester Identity ('attesterIdentity'): mandatory A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. Comment > Previous section says "Attester Identity" is about "a distinguishable Attesting Environment", and here says it's about "a distinguishable Attester". Comment > How to understand "without accompanying evidence about its validity"? Attester Identity ('attesterIdentity'): mandatory In DAA, the Attester's identity is not revealed to the verifier. The Attester is issued with a credential by the Endorser that is randomized and then used to anonymously confirm the validity of their evidence. The evidence is verified using the Endorser's public key. Comment > I think here means the DAA credential represents the Attester Identity. Comment > There is ambiguity of "that is randomized", does it mean randomized Endorser or randomized credential? Comment > For "confirm the validity of their evidence", what does "their" refer to? And what does "the validity of evidence" mean? Authentication Secret IDs ('authSecID'): mandatory A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Evidence. Comment > Previous section says "Authentication Secret" is used to protect Claims, but here says it's used to protect Evidence. Comment > As I understand, if Authentication Secret represents the identity of Attesting Environment, then it's not mandatory, at least in our implementation.
Code change:
without accompanying evidence about its validity - used as proof of identity. <del> The Attester is issued with a credential by the Endorser that is randomised and then used to anonymously confirm the validity of their evidence.  The evidence is verified using the Endorser's public key. </del> _mandatory_ A statement representing an identifier list that MUST be

Related discussion:
text: Authentication Secret IDs ('authSecID'): mandatory In DAA, Authentication Secret IDs are represented by the Endorser (DAA issuer)'s public key that MUST be used to create DAA credentials for the corresponding Authentication Secrets used to protect Evidence. In DAA, an Authentication Secret ID does not identify a unique Attesting Environment but associated with a group of Attesting Environments. This is because an Attesting Environment should not be distinguishable and the DAA credential which represents the Attesting Environment is randomised each time it used. Comment > In my understanding, here says that the DAA credential identities the Attesting Environment. Compared with the description in the "Attester Identity" part, what does the DAA credential represent actually? Reference Claims ('refClaims') mandatory Reference Claims are components of Reference Values as defined in [I-D.ietf-rats-architecture]. [Editor's Note: Definition might become obsolete, if replaced by Reference Values. Is there a difference between Claims and Values here? Analogously, why is not named Reference Claims in the RATS arch?] Comment > I suggest using Reference Values to keep consistent with the RATS arch. Reference Claims are used to appraise the Claims received from an Attester via appraisal by direct comparison. Comment > "Direct comparison" isn't the correct expression, the comparison can have other rules. Claim Selection ('claimSelection'): optional A statement that represents a (sub-)set of Claims that can be created by an Attester. Claim Selections can act as filters that can specify the exact set of Claims to be included in Evidence. An Attester MAY decide whether or not to provide all Claims as requested via a Claim Selection. Comment > The "all Claims" may be ambiguous, I'd like to double check, does it refer to all Claims that the Attester can create or refer to all Claims requested in the Claim Selection? Section 8.1 Challenge/Response Remote Attestation Comment > In the sequence diagram, some elements in the bracket are not defined in the "Information Elements" section, such as targetEnvironment, collectedClaims, eventLog. Should these elements be defined? Section 9 Additional Application-Specific Requirements Depending on the use cases covered, there can be additional requirements. An exemplary subset is illustrated in this section.
Code change:
without accompanying evidence about its validity - used as proof of identity. <del> The Attester is issued with a credential by the Endorser that is randomised and then used to anonymously confirm the validity of their evidence.  The evidence is verified using the Endorser's public key. </del> _mandatory_ A statement representing an identifier list that MUST be

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:
3. <ins> Endpoints advertise their support of the extension described in this document by sending the following transport parameter: A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an acknowledgement.  Values of 0 and 2^14 or greater are invalid, and receipt of these values MUST be treated as a connection error of type PROTOCOL_VIOLATION. An endpoint's min_ack_delay MUST NOT be greater than the its max_ack_delay.  Endpoints that support this extension MUST treat receipt of a min_ack_delay that is greater than the received max_ack_delay as a connection error of type PROTOCOL_VIOLATION.  Note that while the endpoint's max_ack_delay transport parameter is in milliseconds (Section 18.2 in QUIC-TRANSPORT), min_ack_delay is specified in microseconds. 4. </ins> Delaying acknowledgements as much as possible reduces both work done by the endpoints and network load.  An endpoint's loss detection and congestion control mechanisms however need to be tolerant of this

Related discussion:
text: This PR changes a few things: Introduces a TP for negotiating extension use Changes to Makes the fields required Specifies invalid values
I'm merging this, let's address issues in later PRs.
I think it'll be easier to make both parameters required. Not doing so saves 1 to 2 bytes, which is really not much in a frame I expect will be sent a few times a connection. Also, I think 0 should be an invalid value for both params, and 1 should be invalid for the number of packets, though I can see someone arguing that point.
addresses these issues, with the exception that 1 is allowed for packet tolerance. I think that's actually useful for some startup schemes, so we shouldn't disallow it.
Code change:
identifiers have privacy implications; see endpoint-privacy. Each endpoint SHOULD know the identifier of the other endpoint with <del> which its wants to connect and SHOULD compare it with the other </del> <ins> which it wants to connect and SHOULD compare it with the other </ins> endpoint's identifier used in ImportedIdentity.context.  It is however important to remember that endpoints sharing the same group PSK can always impersonate each other.

Related discussion:
text: Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.
Code change:
the calling service via HTTPS and so know the origin with some level of confidence.  They also have accounts with some identity provider. This sort of identity service is becoming increasingly common in the <del> Web environment in technologies such (BrowserID, Federated Google Login, Facebook Connect, OAuth, OpenID, WebFinger), and is often provided as a side effect service of a user's ordinary accounts with some service.  In this example, we show Alice and Bob using a </del> <ins> Web environment (with technologies such as BrowserID, Federated Google Login, Facebook Connect, OAuth, OpenID, WebFinger), and is often provided as a side effect service of a user's ordinary accounts with some service.  In this example, we show Alice and Bob using a </ins> separate identity service, though the identity service may be the same entity as the calling service or there may be no identity service at all.

Related discussion:
text: I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.
Code change:
"struct { Extension extensions<0..2^32-1>; } GroupContextExtensions; " <del> A member of the group applies a GroupContextExtensions proposal by removing all of the existing extensions from the GroupContext object for the group and replacing them with the list of extensions in the proposal.  (This is a wholesale replacement, not a merge.  An extension is only carried over if the sender of the proposal includes it in the new list.)  Note that once the GroupContext is updated, its inclusion in the confirmation_tag by way of the key schedule will confirm that all members of the group agree on the extensions in use. </del> <ins> A member of the group applies a GroupContextExtensions proposal with the following steps: If the new extensions include a "required_capabilities" extension, verify that all members of the group support the required capabilities (including those added in the same commit, and excluding those removed). Remove all of the existing extensions from the GroupContext object for the group and replacing them with the list of extensions in the proposal.  (This is a wholesale replacement, not a merge.  An extension is only carried over if the sender of the proposal includes it in the new list.) Note that once the GroupContext is updated, its inclusion in the confirmation_tag by way of the key schedule will confirm that all members of the group agree on the extensions in use. </ins> 11.1.9.

Related discussion:
text: In order to prevent some other entity from adding an MLS client that does not support a mandatory extension, we already have the KeyPackage Client Capabilities, which lists which extensions are supported by the client.
Note that though this might seem "now or never", I don't think it really is. Consider TLS by way of analogy -- it has no mechanism for specifying that extensions are required. But if a server gets a ClientHello that is missing some extension that it requires, it can just abort the handshake. Likewise in MLS, the member adding a new joiner to the group can examine that joiner's KeyPackage to see if they support the extensions needed for the group. So I think you could implement this as a non-mandatory GroupContext extension, which would state the extensions required by the group so that all members apply the same requirements for new joiners.
While you can implement this "out-of-band", that makes it implicit rather than explicit behavior.
Discussed at 20211004 interim, liked this functionality. But, instead of IANA registry use field (or extension) in group context to indicate which extensions are required. NAME to generate PR.
Discussed with NAME and incorporated this functionality into PR
Code change:
"signer".  If the node is blank or if signature verification fails, return an error. <ins> Verify that the "group_id" is unique among the groups that the client is currently participating in. </ins> Verify the integrity of the ratchet tree. Verify that the tree hash of the ratchet tree matches the

Related discussion:
text: Brendan to revise based on Rohan suggestion.
Interim 2022-05-26: Concerns around making the group_id totally random Malicious group creator can choose it malicious Federated systems get worse randomness Using AEAD.Nk depends on ciphersuite, could be awkward NAME will revise to say: Here are the requirements that group ID must satisfy If you don’t have an alternative plan, do it randomly
Group ids are signed to bind certain information to specific groups. But I can imagine a case where a user mis-uses the group id to be something like a "room title" which lets an adversary control the group id and introduces potential problems. If we can prove that it's fine for a group id to be reused, then should we get rid of group ids? If not (as I expect), then group ids need to be guaranteed to be unique [globally per signing key] and we need to specify that.
Discussed at 19 May interim. NAME to generate PR documenting fresh random value approach.
Virtual interim 2022-05-19: Agreement that some sort of uniqueness requirement is worthwhile Main question is what scope of uniqueness should be Globally? Within scope of DS? Fresh random value? Simple, but precludes application usage of the field Also could help avoid metadata leakage Client / DS should probably still check for collisions NAME to write up a PR on the fresh random value idea
Group IDs must be generated randomly by creator Clients and DS must check that group ids are unique as far as they know
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: Looks good! I would maybe add 1 sentence explaining the rule for what is called a secret and what is called a key. The rule says that a secret will go through some key derivation to obtain a key/keys, is that right?
NAME Yep, that's exactly right. Added a sentence. Thanks for the feedback everyone!
Reopening due to incomplete discussion and inaccuracy. The claims presented are incorrect in response by NAME demonstrate a misunderstanding of the roles of these keys and uses, and constitutes a change to the fundamental uses thereof. The authenticationsecret is NOT a public value nor was it ever introduced as such. If an application is using it as a public value, that onus is on the developers, and I advise against using Cisco's implementation as a standard for MLS. As shown in the name and all original discussion, the authenticationsecret is intended as a secret value (or else 'public' in the same way that the group secret is 'public). It is used for further derivation to support authentication. This should be corrected, and such foundational changes without WG discussion should be avoided.
Clearly we have a disagreement here NAME but maybe let's hold off on attributing misunderstanding. It seems like you are claiming that in order for MLS to be secure, the needs to be protected to the same level as the . What is this based on? If that is true, then we should probably remove the altogether. The "out-of-band" protocol in which it would be confirmed would have to be part of the MLS security analysis, thus no longer out-of-band.
NAME that is not the claim at all - different uses imply different compromise risks. This should not be a new concept to understand. As demonstrated in the terminology, the authenticationsecret is linked to authentication, not confidentiality. MLS, per specification, outsources authentication (the AS is not explicitly defined and all entity authentication within MLS relies on it). Even though it is definitionally out-of-scope and therefore out-of-band (certificates, authentication verification are entirely out-of-band of the protocol spec), we do not say that signature secret keys can be "public" - yet you are asserting that an authenticationsecret which can support epoch-level authentication would be public.
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: The authenticationsecret is private in the same way that the exportervalue is: based on key schedule derivation, compromise of these keys should not undermine MLS, but secrecy of them can be leveraged. So, unless you are now proposing removing mention of certificates, etc. from the core protocol, there really isn't a logical basis for removing 'out-of-band' authentication mechanisms.
What I'm trying to get at here is: What is the negative consequence if an is known by someone other than the members of a group? For example, leaking a signature private key would enable the attacker to impersonate the corresponding member. Leaking the would allow the attacker to decrypt all of the group's messages. What is the bad consequence of an becoming public?
NAME I am also assuming that this push to use epoch-level authentication values as public codes is based on Cisco's implementation choice. I would be curious to know why there is such insistence that all implementations also go about using authentication in the same way. If an implementation chooses to use it as a secret value to then derive an authentication code based on yet other information, why is that a problem?
Publishing the authenticationsecret as a public value has a similar effect as publishing the exportervalue as public - it is not an issue for MLS per protocol spec, but it would definitely be an issue for the application if it is then used for something secret thereafter. One reason not to specify these as public values is that they are derived following the conditions placed on keys and therefore could be used as secret values if desired by an application. Forcing or annotating them as immediately public, or as final 'codes', when such a use as a secret key is an out-of-scope potential is artificial and unnecessary.
I'm not pushing anything, I'm just trying to get the protocol to be clear. If this thing needs to be secret, then it needs to be secret, and we need to document that so that people keep it secret. Thanks for elaborating more on your concerns. I see what you're saying -- basically the same point that NAME and I discussed . I think the core of the disagreement here is what we mean when we say that a value is "public" or "secret".