jiebi/CodeConvo huggingface dataset:
Change:
point that they may recover the entire private key in a few requests, if that key is not really ephemeral. <del> X25519 was designed in a way that the result of X25519(x, d) will never reveal information about d, provided it was chosen as prescribed, for any value of x (the same holds true for X448). All-zeroes output from X25519 or X448 MUST NOT be used for premaster secret (as required by definition of X25519 and X448).  If the premaster secret would be all zeroes, the handshake MUST be aborted (most probably by sending a fatal alert). Let's define legitimate values of x as the values that can be obtained as x = X25519(G, d') for some d', and call the other values illegitimate.  The definition of the X25519 function shows that legitimate values all share the following property: the high-order bit of the last byte is not set (for X448, any bit can be set). Since there are some implementation of the X25519 function that impose this restriction on their input and others that don't, implementations of X25519 in TLS SHOULD reject public keys when the high-order bit of the final byte is set (in other words, when the value of the rightmost byte is greater than 0x7F) in order to prevent implementation fingerprinting.  Note that this deviates from RFC 7748 which suggests that This value be masked. </del> <ins> With X25519 and X448, a receiving party MUST check whether the computed premaster secret is the all-zero value and abort the handshake if so, as described in section 6 of RFC7748. </ins> Ed25519 and Ed448 internally do public key validation as part of signature verification. <del> Other than this recommended check, implementations do not need to ensure that the public keys they receive are legitimate: this is not necessary for security with X25519. </del> 6. The table below defines new ECC cipher suites that use the key

Discussion:
RFC 7748, TLS 1.3, and existing implementations do not check the significant bit. Instead, they mask it off. Align with all of these. Also tweak the all-zeros citation. RFC 7748 describes it as an optional check.
This looks goo to me.
LGTM
Change:
stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS. <ins> This document follows the terminology from I-D.ietf-tls-rfc8446bis where the master secret is renamed to the main secret and the exporter_master_secret is renamed to the exporter_secret. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Discussion:
While reading draft-ietf-emu-eap-tls13-15 I noticed that section now uses which is the named used in but not in RFC 8446 itself. I first thought this was a typo, before a further look showed that this change was mentioned in IETF 110 . Suggestion: make clear which parts need to be looked up from RFC 8446bis. In addition to exporter terminology, the meeting slides above also discuss about usercancelled behavior on slide 10. For clarity, any updates from RFC 8446bis should be marked clearly.
It would be best not to have normative references that block on RFC 8446bis. Perhaps we can just reference that it is renamed from "exportermastersecret"
Sounds good. That should make clear where it comes from and that there's no need to file errata about unknown term and/or RFC 8446bis dependency. Taking another look at my comment about usercancelled behavior on slide 10; to clarify what I was meaning: The slides hint that clarifications in 8446bis are needed by EAP-TLS too. If so, this looks like a reference to RFC 8446bis too. Finally, one nit: the alert name in RFC 8446 is "usercanceled", not "user_cancelled" as in draft -15.
I made a PR with explaining that the document use the terminology from RFC8446bis. URL Do we need to say anything about usercancelled? RFC8446bis might do several clarifications and corrections. I think we should only mention things that are directly relevant for EAP-TLS 1.3 URL Current plan for RFC8446bis seems to be to ignore closenotify and I assume require close_notify after. This does not seem directly relevant for EAP-TLS 1.3. Or?
close issue?
Yes, please close this. I think it's now clear where exportersecret comes from. Also, thanks for the pointer to TLSv1.3 discussion. I agree usercanceled followed by close_notify discussion is not relevant for EAP-TLS 1.3. It's seems to be TLSv1.3 specification and implementation level detail as opposed to something that EAP-TLS 1.3 needs to directly react on.
Change:
Note that gathering phases only gather the candidates needed by new/recycled/restarting m= sections; other m= sections continue to <del> use their existing candidates.  Also, when bundling is active, candidates are only gathered (and exchanged) for the m= sections referenced in BUNDLE-tags, as described in I-D.ietf-mmusic-sdp- bundle-negotiation. </del> <ins> use their existing candidates.  Also, if an m= section is bundled (either by a successful bundle negotiation or by being marked as bundle-only), then candidates will be gathered and exchanged for that m= section if and only if its MID is a BUNDLE-tag, as described in I- D.ietf-mmusic-sdp-bundle-negotiation. </ins> 3.5.2.

Discussion:
I tried to clarify bundle-only while Iw as in here.
BLOCKER: The final paragraph in section 3.5.1 says that candidates are only gathered for m= sections referenced in BUNDLE tags. Section 3.5.4 talks about gathering more candidates than that under certain circumstances. Please make these consistent with each other.
Agree this needs to be rewritten; with BUNDLE, # of media streams is not the number of ICE components.
Change:
Value: a single "SignatureScheme" (RFC8446, Section 4.2.3) to use for authentication. <del> This is equivalent to a literal "signature_algorithms" extension consisting solely of this group. </del> <ins> This is equivalent to a placing a literal "signature_algorithms" extension consisting solely of this group in every extensions field where it is permitted to appear. </ins> In JSON, the signature algorithm is listed by the code point name in RFC8446, Section 4.2.3. (e.g., ecdsa_secp256r1_sha256).

Discussion:
Empty messages must now be included. If the body is known to be empty from the template, this costs one byte. This change also adjusts the explanation of and , and corrects the example.
NAME points out that EndOfEarlyData is an empty message that is semantically meaningful and cannot be predicted by the recipient.
Change:
gathered, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in I-D.ietf-ice-trickle, Section 5.1. <del> Each m= section MUST include the following attribute lines: </del> <ins> I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into different categories.  To avoid unnecessary duplication when bundling, Section 8.1 of I-D.ietf-mmusic-sdp-bundle-negotiation specifies that attributes of category IDENTICAL or TRANSPORT should not be repeated in bundled m= sections. The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section: </ins> An "a=mid" line, as specified in RFC5888, Section 4.  When generating mid values, it is RECOMMENDED that the values be 3

Discussion:
NAME NAME Is this approximately right?
Looks close enough to me - lets land this then tune with future PRs
LG with nits
Change:
The actual content type of the record is found in fragment.type after decryption. <del> The record_version field is identical to TLSPlaintext.record_version and is always { 3, 1 }.  Note that the handshake protocol including the ClientHello and ServerHello messages authenticates the protocol version, so this value is redundant. </del> <ins> The legacy_record_version field is identical to TLSPlaintext.legacy_record_version and is always { 3, 1 }.  Note that the handshake protocol including the ClientHello and ServerHello messages authenticates the protocol version, so this value is redundant. </ins> The length (in bytes) of the following TLSCiphertext.fragment, which is the sum of the lengths of the content and the padding,

Discussion:
From the past three times we've bumped the version, reality has unequivocally told us that the TLS version negotiation, as described in previous specifications, has been a collossal failure. The working group decided not to replace the mechanism with a more sustainable one, so do the next best thing in trying to save TLS from itself. If the fields are renamed to what they actually are ('serverversion' is the true version and 'clientversion' is a maximum), then perhaps we'll have some hope of future implementors getting it right, if we ever clear through the prior iterations of the bug. While I'm here, remove the mention of 'The protocol version the current record is compatible with' for recordversion. recordversion is purely vestigial.
+1
This sounds like a good idea, however for the server version I'd go with "negotiatedversion" to be more precise. For "recordversion", we could also extend the "legacy" prefix convention we've started using and change it to "legacyrecordversion" to remind that it's a deprecated field.
Hrm. We don't name other fields like ServerHello.negotiatedciphersuite and such. Though if we wanted to be consistent with those fields, it should be ClientHello.maxversion rather than ClientHello.maxsupportedversion. Dunno, maybe that would be better... maxsupported_version is a bit wordy. (Though I do think breaking pattern on the ClientHello version is justified because that field is already inconsistent with everything else in TLS. The version is the only place where the client doesn't offer a list, so everything else already self-describes as a "pick one of these" type of field.) Done.
Change:
appropriate prior version of TLS. <del> Clients MAY request extended functionality from servers by sending </del> <ins> Clients request extended functionality from servers by sending </ins> data in the extensions field.  The actual "Extension" format is defined in hello-extensions.

Discussion:
Small simplification & clarification. Now that the server key share is in an extension, all TLS 1.3 endpoints will have at least one extension in their hello, either "keyshare" or "preshared_key", at minimum. This changeset simplifies the ServerHello struct in the same manner as was previously done for ClientHello and adds short notes explicitly stating this.
Change:
The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations can <del> interoperate and to form federated systems. </del> <ins> interoperate and to form federated systems if they use compatible wire encodings. </ins> 3.1.7.

Discussion:
Remove "join an existing group" from architecture doc, based on UserAdd having been removed from the protocol doc. Remove statement that message delivery cannot be correlated between AS identities and DS delivery channels. This seems generally very difficult to achieve. It may be possible at times, but does not seem to be grounded in discussions that we have had at the working group meetings. Note that federation requires compatible wire encodings. Note that communication with the AS requires TLS or alternative authentication. Note that out-of-band channels may facilitate detection of misbehaviour. Some grammar fixes.
Change:
Object Notation (JSON) RFC8259 and one using the Concise Binary Object Representation (CBOR) RFC7049, which can be used with the CoAP FETCH, PATCH, and iPATCH methods for resources represented with the <del> SenML data model.  The rest of the document uses term "(i)PATCH" when referring to both methods as the semantics of the new media types are the same for the CoAP PATCH and iPATCH methods. </del> <ins> SenML data model (i.e., for both SenML and Sensor Streaming Measurement Lists (SenSML) data).  The rest of the document uses term "(i)PATCH" when referring to both methods as the semantics of the new media types are the same for the CoAP PATCH and iPATCH methods. </ins> 2.

Discussion:
more details for security consideration on record names noted this applies to SenSML too updated extensibility mechanism
The CI checks fail because this PR has still year 2019 in the draft. The PR fixes that too.
Change:
8. The ratchet tree for an epoch describes the membership of a group in <del> that epoch, providing public-key encryption keys that can be used to encrypt to subsets of the group as well as information to </del> <ins> that epoch, providing public-key encryption (HPKE) keys that can be used to encrypt to subsets of the group as well as information to </ins> authenticate the members.  In order to reflect changes to the membership of the group from one epoch to the next, corresponding changes are made to the ratchet tree.  In this section, we describe

Discussion:
Changes (apart from editorial): Remove the text about the key schedule. Reason: I found the text confusing, because updating paths provides FS and PCS for the HPKE keys in the ratchet tree, and not directly for the key schedule. Generate the leaf key pair simply as a fresh HPKE key pair, and not from the leafsecret. I couldn't see any benefit of using the leafsecret. I wonder if there is a good reason?
I am concerned that we are asking for a LOT of fresh entropy if (in addition to nonces) we need a crypto-random value every epoch for every group (a Wire client can easily a member of thousands of groups at a time). Do you have a concern about deriving it?
Discussion on the virtual interim: To NAME concern: This allows the base path secret to be derived, e.g., using a KDF, so this doesn't necessarily increase the amount of entropy needed Clear to merge
Change:
Secret changes (e.g., when changing from the handshake to application data keys or upon a key update). <del> 7.3.1. </del> <ins> 7.4. </ins> <del> A conventional Diffie-Hellman computation is performed.  The negotiated key (Z) is converted to byte string by encoding in big- endian, padded with zeros up to the size of the prime.  This byte string is used as the shared secret, and is used in the key schedule as specified above. </del> <ins> 7.4.1. For finite field groups, a conventional Diffie-Hellman computation is performed.  The negotiated key (Z) is converted to byte string by encoding in big-endian, padded with zeros up to the size of the prime.  This byte string is used as the shared secret, and is used in the key schedule as specified above. </ins> Note that this construction differs from previous versions of TLS which remove leading zeros. <del> 7.3.2. </del> <ins> 7.4.2. </ins> For secp256r1, secp384r1 and secp521r1, ECDH calculations (including parameter and key generation as well as the shared secret

Discussion:
Exporters and (EC)DHE secrets are not traffic secrets. Group the two (EC)DHE sections under a name which matches what the key schedule section calls it (the "(EC)DHE shared secret") and link to it from the key schedule.
Change:
HMAC(finished_secret, finished_label + '0' + handshake_hash) <del> where HMAC uses the Hash algorithm for the handshake.  See the- handshake-hash for the definition of handshake_hash. </del> <ins> where HMAC RFC2104 uses the Hash algorithm for the handshake.  See the-handshake-hash for the definition of handshake_hash. </ins> For Finished messages sent by the client, the string "client

Discussion:
Use refs for HKDF & HMAC in the document and drop the unused AES CBC RFC ref in favor of the AES GCM RFCs (refs already in use). Caught via Travis warnings that they were all unused. It also notes that RFC 2246 (TLS 1.0) isn't referenced directly and RFC 5705 isn't used, either. NAME You probably wanted to reference RFC 5705 somewhere in your recent work, but it's not currently used. Travis also complains about I-D.ietf-tls-session-hash, though that is referenced in the credits. It probably should be referenced somewhere too.
I've also added an update to the "obsoletes" line. We don't need to list TLS 1.1 (TLS 1.2 & 1.3 don't list 1.0), its extensions RFC, or AES CBC, as they've already been obsoleted by TLS 1.2 (also obsoleted old AES RFC) and the newer extensions RFC.
Change:
copied from the value of the "hosts" relation and overwritten by the value of the con query parameter. <del> Links are modelled as they are in fig-ER-WKC.  As they do not have their ".well-known/core" document associated with them any more which would originally provide its Base URI, the "con" attribute of the registration fills that gap and is used as a Base URI. </del> <ins> Links are modelled as they are in fig-ER-WKC. </ins> 3.4.

Discussion:
This is the first step to closing [54], doing the changes to the model itself. Won't close the issue by itself probably, as some other portions might mention the model. This does not try to address any of the open issues. [54]: URL
s taget/target/
Change:
[TODO: define how we want to structure this registry when the time comes] <del> 7.2. </del> <ins> 7.3. </ins> The following value [will be/has been] registered in the "IETF URN Sub- namespace for Registered Protocol Parameter Identifiers"

Discussion:
NAME -- is it better practice to define media types per protocol message, or to define a single media type for all protocol messages?
Generally, if they're different formats -- e.g., they have different schema, or just different syntax -- they need different media types (or an explicitly generic one like ). If it's one format that has different uses, you can give it a single media type and then switch contexts based upon internal flags. The real question, though, is whether you have any potential for use cases where it's important for generic software that's handling these messages to do different things based upon the media type.
I don't think there'd ever be generic software using these types (beyond the HpkeConfig?). Most messages are meant to be consumed by PPM and PPM alone. I moved protocol messages to the "message" registry space and kept the HpkeConfig in the application type space, and also left all intended usage fields as COMMON. I also added an open issue to have someone more familiar with these registries give these allocation requests a review. NAME this should be good to go based on the above.
Currently, DAP uses the following media types (defined in section 7.1): Note that the first uses the top-level type, while the remainder use the top-level type. For consistency, I suggest we use the same top-level type for all messages. Which type is more appropriate? Per : is for "either uninterpreted binary data or information to be processed by an application" is for "an encapsulated message"; all of the motivating examples (see section 5.2) are around encaspulating one message format inside another, or fragmenting a message into multiple chunks. provides further guidance that "multipart and message are composite types; that is, they provide a means of encapsulating zero or more objects, each one a separate media type." Given that DAP messages are not a method of encapsulating a message of a different type, I suggest that is the more appropriate top-level type to use. This is also supported by the rather large number of media types vs the relatively tiny number of media types in . (this issue fell out of discussion on URL)
Agreed, seems better.
The types were chosen in PR on a tentative basis, and marked with "OPEN ISSUE: Solicit review of these allocations from domain experts."

Based on the encapsulation reasoning, I agree that be most appropriate for our media types.
LGTM except for the hed.
Change:
A test expression either tests the existence of a node designated by an embedded query (see extest) or tests the result of a function expression (see fnex).  In the latter case, if the function <del> expression is of type "OptionalBoolean" or one of its subtypes, it tests whether the result is "true"; if the function expression is of type "OptionalNodes" or one of its subtypes, it tests whether the result is different from "Nothing". </del> <ins> expression is of type "OptionalBooleanType" or one of its subtypes, it tests whether the result is "true"; if the function expression is of type "OptionalNodesType" or one of its subtypes, it tests whether the result is different from "Nothing". </ins> Parentheses MAY be used within "boolean-expr" for grouping.

Discussion:
This is literally just a renaming of the names in the Type column of Table 13. I also noticed that the description doesn't account for non-nodelist inputs. I'll open another issue for that.
If I'm reading the right, it looks like the term is being used to mean different things depending on which column it's in. In column 1 ("Type") or column 3 ("Subtypes"), it's referring to the type system we're creating. In column 2 ("Abstract Instances"), it's referring to the underlying JSON(ish) value kind, i.e. , , , etc, plus . I think having the same word to define these things can be confusing for the reader, and maybe we need something else in one of these places to indicate the distinction. We've already done this for the type to distinguish it from the value.
I'm not sure there is a really good alternative. We could use for abstract instances, but in the rest of the spec, "value" implies a JSON value, so this doesn't seem quite right.
If "value" implies a JSON value (corresponding to the middle column), then we should change the others (the type name). It really is confusing.
In the interim, we decided to append the type names with "Type". I will create a PR for this.
I'm going to wait for to complete before going forward with this as they change the same chunk of text.
Thanks. That's why I am trying to tidy up and get it merged ASAP.
Thanks!
Change:
This cookie only proves IP address ownership.  Any rate limiting scheme can be applied to packets coming from non-spoofed addresses. <del> 3.9.2. </del> <ins> 3.8.2. </ins> Optional PSK-based session creation.

Discussion:
Sort the protocols we describe based on perceived importance, popularity, etc. Basically, put non-standard ones at the end, and all else towards the front.
Correct!
I'm assuming the content itself hasn't changed, just moved around? It's not obvious from the diff, so LMK if not and I'll un-approve.
Change:
In networks managed using DNS-SD, the use of DNS-SD for discovery as described in rd-using-dnssd is recommended. <del> The use of multicast discovery in mesh networks is NOT recommended. </del> <ins> The use of multicast discovery in mesh networks is NOT RECOMMENDED. </ins> 4.1.1.

Discussion:
Thanks, merged. (If questions come up around the normative-language RECOMMENDED: I agere that from the capitals NOT before it, this was already intended to be normative.)
Change:
Clients MUST discard Retry packets that have a Retry Integrity Tag that cannot be validated; see the Retry Packet Integrity section of <del> QUIC-TLS.  This diminishes an off-path attacker's ability to inject a Retry packet and protects against accidental corruption of Retry packets.  A client MUST discard a Retry packet with a zero-length Retry Token field. </del> <ins> QUIC-TLS.  This diminishes an attacker's ability to inject a Retry packet and protects against accidental corruption of Retry packets. A client MUST discard a Retry packet with a zero-length Retry Token field. </ins> The client responds to a Retry packet with an Initial packet that includes the provided Retry Token to continue connection

Discussion:
We weren't being consistent. This should help.
NAME said:
The first here is in the process of being addressed, see . I agree regarding "strong", but also agree regarding what to do about it. My proposal is to let close this issue.
NAME said:
Proposed resolution is URL
This is an improvement. Thanks.