jiebi/CodeConvo huggingface dataset:
Change:
The JSON value the JSONPath query is applied to is, by definition, a valid JSON value.  The parsing of a JSON text into a JSON value and what happens if a JSON text does not represent valid JSON are not <del> defined by this specification. When a JSONPath query is applied to a JSON value containing an object with duplicate names, the behaviour is unpredictable.  (Such a value usually originates in JSON text containing an object with duplicate keys, but how such a value could be constructed depends on how the JSON text is parsed and how the parsed value is represented.) </del> <ins> defined by this specification.  Sections RFC8259 and RFC8259 of RFC8259 identify specific situations that may conform to the grammar for JSON texts but are not interoperable uses of JSON, for instance as they may cause unpredictable behavior.  The present specification does not attempt to define predictable behavior for JSONPath queries in these situations.  (Note that another warning about interoperability, in RFC8259, at the time of writing is generally considered to be overtaken by events and causes no issues with the present specification.) Specifically, the "Semantics" subsections of Sections dot-selector, wildcard, index-selector, index-wildcard-selector, filter-selector, and descendant-selectors describe behavior that turns unpredictable when the JSON value for one of the objects under consideration was constructed out of JSON text that exhibits multiple members for a single object that share the same member name ("duplicate names", see RFC8259).  Also, matching (selectors) and comparing (comparisons in Section filter-selector) of strings assumes these strings are sequences of Unicode scalar values, turning unpredictable if they aren't (RFC8259). </ins> 3.2.

Discussion:
Centralize the text that explains how non-interoperable JSON may cause unpredictable behavior. This is a little clumsy as the sections to be referenced are currently unnumbered.
Solves a few "behaviours", too :-)
This centralizing approach is a good thing. I suggest to reuse the phrase "duplicate names" for better recognition of the wording in RFC8259, though is more general, as it addresses more than two.
There may be scope for fine-tuning the section cross-referencing, but this can be deferred to purely editorial activity
Change:
This is a new section when compared to RFC5216. To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS <del> server MUST send one or more NewSessionTicket messages (each containing a PSK, a PSK identity, a ticket lifetime, and other parameters) in the initial authentication.  Note that TLS 1.3 RFC8446 limits the ticket lifetime to a maximum of 604800 seconds (7 days) and EAP-TLS servers MUST respect this upper limit when issuing </del> <ins> server MUST send one or more Post-Handshake NewSessionTicket messages (each associated with a PSK, a PSK identity, a ticket lifetime, and other parameters) in the initial authentication.  Note that TLS 1.3 RFC8446 limits the ticket lifetime to a maximum of 604800 seconds (7 days) and EAP-TLS servers MUST respect this upper limit when issuing </ins> tickets.  The NewSessionTicket is sent after the EAP-TLS server has received the client Finished message in the initial authentication. <del> The PSK associated with the ticket depends on the client Finished and cannot be pre-computed in handshakes with client authentication.  The NesSessionTicket MUST NOT be sent before the client's certificate has been validated.  The NewSessionTicket message MUST NOT include an </del> <ins> The NewSessionTicket can be sent in the same flight as the TLS server Finished or later.  The PSK associated with the ticket depends on the client Finished and cannot be pre-computed in handshakes with client authentication.  The NewSessionTicket message MUST NOT include an </ins> "early_data" extension.  If the "early_data" extension is received then it MUST be ignored.  Servers should take into account that fewer newSessionTickets will likely be needed in EAP-TLS than in the usual

Discussion:
During dicsussion on close_notify, there was a good dicusssion on the list on why resumption is needed. Some short clarifications on how TLS 1.3 works. E.g. that PSK is not included in the ticket.
Change:
while scripts are allowed to make HTTP requests via the XMLHttpRequest() API those requests are not allowed to be made to any server, but rather solely to the same ORIGIN from whence the script <del> came xref target="RFC6454"/> (although CORS CORS and WebSockets RFC6455 provide a escape hatch from this restriction, as described below.)  This SAME ORIGIN POLICY (SOP) prevents server A from mounting attacks on server B via the user's browser, which protects both the user (e.g., from misuse of his credentials) and the server B (e.g., from DoS attack). </del> <ins> came RFC6454 (although CORS CORS and WebSockets RFC6455 provide a escape hatch from this restriction, as described below.)  This SAME ORIGIN POLICY (SOP) prevents server A from mounting attacks on server B via the user's browser, which protects both the user (e.g., from misuse of his credentials) and the server B (e.g., from DoS attack). </ins> More generally, SOP forces scripts from each site to run in their own, isolated, sandboxes.  While there are techniques to allow them

Discussion:
As discussed, a couple of minor typos and corrections.
The travis failures here aren't Michael's fault.
I've looked up the missing reference dates and added them. Travis seems happier.
Change:
they do not recognize; this allows problem types to evolve and include additional information in the future. <del> 3.1. </del> <ins> 5.1. </ins> The example in fig-example-ext-full has all the basic elements as well as an additional, type-specific element. <del> 4. </del> <ins> 6. </ins> Problem Details for CoAP APIs are serialized in the CoRAL binary format.  See Section 11 of RFC7252 for security considerations

Discussion:
Note that this PR sits on top of
CoAP Response Codes are an optional feature and should be discussed in a separate section. Rationale for the feature The CoAP response-code is already carried by the CoAP header, so it doesn't make sense adding it to the PD payload that goes from Server to Client. It does however make sense for a Client that is about to ingest the received PD into a log pipeline to "enrich" it with ancillary Information from the underlying CoAP transaction. In this context, response-code is probably the most basic attribute that one wants to carry over as it is also commonly used as a high-level partition key for log visualisation.
addressed by
We should provide a default set of ready-to-use PD types associated with the existing CoAP status codes, intended for carrying (and enriching) the associated status code semantics. The (rough) plan is to define an “about:coap” namespace with one PD type for each registered . An application could use such PDs without the need to register anything. Just pick the "right" type and populate the relevant fields, job done. As a nice side-effect, this would allow exercising the registration procedure, including the definition of the PD type's registry structure and providing a first set of registrations.
Change:
Upon receipt of trickled candidates, the receiving application will supply them to its ICE Agent.  This triggers the ICE Agent to start <del> using the new remote candidates for connectivity checks.  If BUNDLE is in use, each candidate is only supplied once, and is associated with the m= section which matches the sender's BUNDLE-tag. </del> <ins> using the new remote candidates for connectivity checks. When BUNDLE is in use, candidates (both in-SDP and trickle) are only exchanged for and associated with the m= section referenced by the sender's BUNDLE-tag, as described in I-D.ietf-mmusic-sdp-bundle- negotiation </ins> 3.4.2.1.

Discussion:
First cut. Need to update the examples.
Overall LG, a handful of comments
LGTM
lgtm and merged. Will do a new PR to handle minor tweaks
BUNDLE draft 27 (URL) indicates that ICE attributes and candidates in re-offers (and with max-bundle, I'm guessing) should only be in the "m=" line associated with the offerer BUNDLE-tag. In other words, the candidates and ICE parameters are not duplicated unnecessarily across m= sections. We should update JSEP to reflect this.
Change:
IANA, please update these two registries to refer to this document. <del> IANA has already assigned the value 29 to ecdh_x25519, and the value 30 to ecdh_x448. </del> <ins> IANA is requested to assigned the value 29 to x25519, and the value 30 to x448 in the TLS Supported Groups Registry.  This replaces the temporary registrations ecdh_x25519(29) and ecdh_x448(30). </ins> IANA is requested to assign two values from the TLS SignatureAlgorithm Registry with names ed25519(TBD3) and ed448(TBD4)

Discussion:
ecdhx25519 and ecdhx448 no longer have an ecdh_ prefix (.Remove some remnants of EdDSA curves as NamedCurves.TLS 1.3 only uses the PureEdDSA algorithms. If we were to use Ed25519ph, we would want separate SignatureAlgorithm values so the receivers can indicate support.
(NAME suggested I file this here.) In TLS 1.3, we dropped the "ecdh" prefix on ecdhx25519 and ecdh_x448 when we split signatures from NamedCurve/Group. The documents should probably match in naming one way or another. I think plain x25519 and x448 is tidier. X25519 already denotes the ECDH function, as opposed to curve25519 which is the curve.
Looks fine to me
Change:
previous last lifetime set on a previous update or the original registration (falling back to 86400) SHOULD be used. <del> Context (optional).  This parameter sets the scheme, address and port at which this server is available in the form scheme://host:port/path.  In the absence of this parameter the scheme of the protocol, source address and source port of the register request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  When con is used, scheme and host are mandatory and port and path parameters are optional. </del> <ins> Context (optional).  This parameter updates the context established in the original registration to a new value.  If the parameter is set in an update, it is stored by the RD as the new Base URI under which to interpret the links of the registration, following the same restrictions as in the registration.  If the parameter is not set and was set explicitly before, the previous context value is kept unmodified.  If the parameter is not set and was not set explicitly before either, the source address and source port of the update request are stored as the context. </ins> application/link-format (mandatory)

Discussion:
This is the documenting text to the changes worked out first on the examples in . It does not (yet) contain explaining overall text, but updates the various smaller mentions of the parameter to fit together. It does change the semantics of using on a registration update, but I believe that the previous wording was not what the original authors had intended. (Previously, an endpoint registering over TCP would need to explicitly repeat its con on every update).
Change:
properties TLS does and does not provide and cannot safely rely on the latter. <del> Note in particular that type and length of a record are not protected by encryption.  If this information is itself sensitive, application </del> <ins> Note in particular that the length of a record is not protected by encryption.  If this information is itself sensitive, application </ins> designers may wish to take steps (e.g., padding, cover traffic) to minimize information leakage.

Discussion:
This pull request has been updated to the current master
Consensus at meeting to merge this PR with updates and with the dummy type byte restored. NAME has action item to actually measure whether we can strip off the now fixed type, record.version bytes.
I've updated this with the expected changes: dummy external ContentType octet is restored, and URL is after fragment.content instead of the other way around (to make it easier to encrypt without having to shuffle buffers).
I agree with davegarrett's suggestion about field naming here, and have supplied a change implementing it.
TLSCiphertext.recordversion provides no useful information, encourages implementations to check it unnecessarily, and wastes two bytes per record. It should be removed entirely. This is effectively dependent on PR or similar changes. Filing this as a specific issue rather than just bringing it up in backwards compatibility discussion. Edited to add: Note that this value is called TLSCiphertext.version in TLS 1.2 and TLSCiphertext.recordversion as of TLS 1.3 draft 06. The TLSPlaintext equivalent of this version field cannot be removed as it is required for backwards compatibility, however it's only used with ClientHello at this point.
Defer pending measurements. Note that this fate shares with removing the cleartext content type
sgtm Amending issue title.
Mozilla is working on measurements.
Change:
If servers simply increment the nonce by one with each generated connection ID, then it is safe to use the existing keys until any <del> server's nonce counter exhausts the allocated space and rolls over to zero.  Whether or not it implements this method, the server MUST NOT </del> <ins> server's nonce counter exhausts the allocated space and rolls over. To maximize entropy, servers SHOULD start with a random nonce value, in which case the configuration is usable until the nonce value wraps around to zero and then reaches the initial value again. Whether or not it implements the counter method, the server MUST NOT </ins> reuse a nonce until it switches to a configuration with new keys. Both the Plaintext CID and Encrypted Long CID algorithms send parts

Discussion:
Alright NAME NAME I've incorporated feedback from both of you and the one crypto review we've received. I suggest you read all of section 5.2 (## Encrypted Short CID Algorithm) to see what I've done, as this is a total rewrite.
Looks good.
Change:
reflect them as already valid in any orders submitted by the client. If a CA wishes to allow pre-authorization within ACME, it can offer a <del> "new authorization" resource in its directory by adding the key "new- authz" with a URL for the new authorization resource. </del> <ins> "new authorization" resource in its directory by adding the field "new-authz" with a URL for the new authorization resource. </ins> To request authorization for an identifier, the client sends a POST request to the new-authorization resource specifying the identifier

Discussion:
In the JSON , could be called a "field name" or a "key." We use both in this document, but we should consolidate one one. I think "field name" is better (and NAME agrees). In part this avoids any ambiguity with cryptographic keys.
Change:
Attacks that rely on non-ECH traffic to infer server identity in an ECH connection are out of scope for this document.  For example, a client that connects to a particular host prior to ECH deployment may <del> later resume a connection to that same host after ECH deployment, thereby linking the resulting ECH connection to the original non-ECH connection. </del> <ins> later resume a connection to that same host after ECH deployment.  An adversary that observes this can deduce that the ECH-enabled connection was made to a host that the client previously connected to and which is within the same anonymity set. </ins> 10.7.

Discussion:
cc NAME
(Filing this as a separate ticket so I don't forget to propose new text.) added this text: I think this statement is a bit strong and overstates the issue. It reads as if resuming connections across ECH and non-ECH links the two connections. If we're talking about someone other than the server, this isn't true. Tickets are issued encrypted and, in ECH, even sent encrypted. Even if they were sent in the clear, TLS 1.3's protects against such correlations. Rather, the correlation in is a much weaker one: based on either the size of the ClientHello or whether the server accepted the ticket, you learn a single bit for whether it was some previous connection made by that client. You don't know which previous connection it was, and you don't know if it was an ECH connection or a non-ECH connection. In fact what you learn... more-or-less aligns with the anonymity set. See URL (If we're talking about the server, yes, resuming allows the server to link the two connections. That's fundamental to resumption and is in the purview of URL I don't think most applications would consider ECH vs non-ECH a correlation boundary w.r.t. the server itself.)
The original text doesn't necessarily imply that on-the-wire tickets are the linking factor. Rather that the shape of the handshake, time it takes to complete, etc, can be a proxy for whether or not resumption occurred. I don't think we need to change anything here. (But I also would not object to someone else sending a PR!)
(This came up in a discussion between me and NAME So, the current text says "For example, a client that [does X] may [do Y], thereby linking the resulting ECH connection to the original non-ECH connection". That implies that doing X and Y allows linking the two connections together. You're right that tickets may not be the only linking factor, but the other channels don't let you link connections, only, as you say, whether or not resumption occurred. That single boolean doesn't tell you which non-ECH connection corresponded to the ECH connection, or what the name was. It only tells you that it's the same name as some previous connection to the anonymity set.

It might be a non-ECH one (but you don't know which) or it might be an ECH one.
Feel free to suggest text to reword this. I think the example was meant to be general enough to suggest that side channels exist. I definitely do not feel strongly about the exact wording here.
I agree that the text as-is overstates the issue.
Thanks!LGTM -- thanks!
Change:
be used to indicate the default.  Only full coverage is guaranteed, any other requests are advisory. <del> 7.1.6. </del> <ins> 7.1.7. </ins> This enumerated property specifies the application's preferred tradeoffs for sending this Message; it is a per-Message override of

Discussion:
Satisfies
Okay, addressed capitalization and took Brian's suggested paragraph (with one tiny change).
Fine with me - go ahead
NAME NAME any further comments on this one?
ship it
Sorry, seems I should have clicked "approve" earlier. Still being clumsy in github :(
Change:
Abstract This document provides usage guidance for external Pre-Shared Keys <del> (PSKs) in TLS.  It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document also discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  It provides advice for applications in various use cases to help meet these assumptions. Privacy and security properties not provided by PSKs are also included. </del> <ins> (PSKs) in Transport Layer Security (TLS) version 1.3 as defined in RFC 8446.  It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  It discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  It provides advice for applications in various use cases to help meet these assumptions.  It also lists the privacy and security properties that are not provided by TLS when external PSKs are used. </ins> 1. <ins> This document provides guidance on the use of external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) version 1.3 RFC8446. This document lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  This document also provides advice for applications in various use cases to help meet these assumptions. </ins> There are many resources that provide guidance for password generation and verification aimed towards improving security. However, there is no such equivalent for external Pre-Shared Keys <del> (PSKs) in TLS.  This document aims to reduce that gap.  It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks. This document also discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  It provides advice for applications in various use cases to help meet these assumptions. </del> <ins> (PSKs) in TLS.  This document aims to reduce that gap. </ins> The guidance provided in this document is applicable across TLS RFC8446, DTLS I-D.ietf-tls-dtls13, and Constrained TLS I-D.ietf-tls-

Discussion:
Resolve comments from Ben Smyth.
NAME can you please cut a new version of the draft?
Done. Revision -02 has been submitted.
I am getting a permission error when I try to set the tag for "draft-ietf-tls-external-psk-guidance-02". Everything else is done, and I have used my local file to submit the Internet-Draft. Please set the tag when you have a minute.
Change:
4.2. <ins> When sending data to a TURN RFC5766 server, the sending client tells the server the destination IP and port for the data.  This means that if the client uses TURN to send to an IP that was obtained by mDNS resolution, the TURN server will learn the underlying host IP and port, and this information can then be relayed to the web application, defeating the value of the mDNS wrapping. To prevent disclosure of the host IP address to a TURN server, the ICE agent MUST NOT form candidate pairs between its own relay candidates and remote mDNS candidates.  Note that the converse is not an issue; the ICE agent MAY form candidate pairs between its own mDNS candidates and remote relay candidates, as in this situation host IPs will not be sent directly to the TURN server. This restriction has no effect on connectivity; in the cases where host IP addresses are private and need to be wrapped with mDNS names, they will be unreachable from the TURN server, and as noted above, the reverse path will continue to work normally. 4.3. </ins> It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname candidate would provide applications an even more reliable tracking

Discussion:
LGTM too, will resolve conflicts
If we resolve a name N1 to 1.1.1.1, should we pair it with relay candidates? If we do so, 1.1.1.1 will be sent to the TURN server, which seems like a leak (could be under the control of the web app). Probably need to add a section in the privacy considerations saying any remote mdns candidates MUST NOT be paired with local relay candidates (although the reverse should be OK).
I am thinking about the impact on the connectivity, and if we can ever resolve the remote mdns candidate, the chance of selecting relaymdns even if this is allowed could probably be low if the local side also gathers a host candidate. The MUST level lgtm.
yeah, and keep in mind that usually these host IPs will be things like 192.168.1.3 that are not even reachable by the outside world.
Well thought! Agreed, I always thought TURN and STUN were intertwined (TURN server is probably also a STUN server or at least hosted in the same network) so that we can use server reflexive candidates for TURN without losing much.
yeah - we already throw away private IPs for TURN to avoid creating connections that won't work, so the actual impact here is negligible.
LGTM