jiebi/CodeConvo huggingface dataset:
Change:
exchange.  Low entropy keys are only secure against active attack if a PAKE is used with TLS.  The Crypto Forum Research Group (CFRG) is currently working on specifying a standard PAKE (see I-D.irtf-cfrg- <del> cpace and I-D.krawczyk-cfrg-opaque). </del> <ins> cpace and I-D.irtf-cfrg-opaque). </ins> 5.

Discussion:
Builds on , and , and . cc NAME NAME NAME -- please review so we can submit today!
There are two numbered lists both of which only seem to have 1s? I see that you have removed the text on security weaknesses of PSKs (lack of identity protection/forward secrecy etc.) and also removed the reference to RFC 8773. I am completely fine with both as long as we provide a convincing answer to John's review.
Markdown handles the numbering for us. We have a section on identity protection, and the recommendations discuss forward secrecy, so I think more is redudant. No, that's still there.
John wrote: There also several weaknesses/limitation that are hinted at in RFC 8446 which apply for two-party PSK authenticated connections. As this is a guidance document for all uses of external PSK, I think this document should bring up and expand upon: Key Compromise Impersonation (KCI) resistance Protection of endpoint identities Forward secret with respect to long-term keys (psk_ke only) An additional security property given by signature authentication but not psk authentication is non-repudiation. As stated by Wikipedia “By this property, an entity that has signed some information cannot at a later time deny having signed it.”
This is a fair comment and I don't see any reason not to add these
NAME can you please send a PR?
Closing as resolved (by ).
The draft says “OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites.” John wrote: I assume this is not the case for TLS 1.3 as the cipher suites in TLS 1.3 are independent of the authentication.
I guess it would help to clarify. In my opinion, we should only look at APIs of TLS 1.3.
I fixed this directly on main.
The draft currently says "It is NOT RECOMMENDED to share the same PSK between more than one client and server." John says: group PSK violates both “peer authentication” and “downgrade protection property”. It also violates “secrecy of the session keys”. Two-party PSK already does not provide “Key Compromise Impersonation (KCI) resistance” and “Protection of endpoint identities” and pskkey does not provide “Forward secret with respect to long-term keys”.

So when pskke is used in a group, the only property left is “Uniqueness of the session keys”...I am skeptical to introduce this new group PSK mode in an informal guidance document. If group PSK should be allowed, it should be more clearly declared as a new mode of TLS 1.3 and the security properties given and not given should be more clearly stated.
I guess John thinks NOT RECOMMENDED is not sufficient and we should stronger language like SHALL NOT.
Change:
perspective, a session is established once it sends a 2xx response. WebTransport over HTTP/3 does not support 0-RTT. <ins> The "webtransport" HTTP Upgrade Token uses the Capsule Protocol as defined in HTTP-DATAGRAM. </ins> 3.4. From the flow control perspective, WebTransport sessions count

Discussion:
This PR keeps WebTransport in sync with the latest changes in draft-ietf-masque-h3-datagram.
Change:
If NAT traversal is required, the process of gathering Local Endpoints becomes broadly equivalent to the ICE candidate gathering <del> phase RFC5245.  The endpoint determines its server reflexive Local Endpoints (i.e., the translated address of a local, on the other side of a NAT) and relayed locals (e.g., via a TURN server or other relay), for each interface and network protocol.  These are added to the set of candidate Local Endpoints for this connection. </del> <ins> phase (see Section 5.1.1. of RFC8445).  The endpoint determines its server reflexive Local Endpoints (i.e., the translated address of a local, on the other side of a NAT, e.g via a STUN sever RFC5389) and relayed locals (e.g., via a TURN server RFC5766 or other relay), for each interface and network protocol.  These are added to the set of candidate Local Endpoints for this connection. </ins> Gathering Local Endpoints is primarily a local operation, although it might involve exchanges with a STUN server to derive server reflexive locals, or with a TURN server or other relay to derive relayed <del> locals.  It does not involve communication with the Remote Endpoint. </del> <ins> locals.  However, it does not involve communication with the Remote Endpoint. </ins> 4.1.1.2.

Discussion:
and spell out ICE.
I also updated a later reference and added references for STUN and TURN in this same PR now.
Change:
proxy MUST keep the socket open while the CONNECT-UDP stream is open. Proxies MAY choose to close sockets due to a period of inactivity, but they MUST close the CONNECT-UDP stream before closing the socket. <ins> If a proxy is notified by its operating system that its socket is no longer usable, it MUST close the CONNECT-UDP stream. </ins> 6.

Discussion:
This is partly related to URL but seems to fit its own issue. Let's assume a CONNECT-UDP request succeeds with a 2xx and a flow of datagrams is merrily exchanged. How do endpoints indicate they are done with the stream and associated flows? The spec doesn't really say anything. The main example I can think of is where a server decides to perform housekeeping on UDP connections (maybe as part of runtime garbage collection, or in reaction to the network stack throwing errors) after a 2xx was been sent. H3 CONNECT says ends the request stream (that is, the receive stream at the proxy enters the "Data Recvd" state), the proxy will set the FIN bit on its connection to the TCP server. When the proxy receives a packet with the FIN bit set, it will close the send stream that it sends to the client. TCP connections that remain half-closed in a single direction are not invalid, but are often handled poorly by servers, so clients SHOULD NOT close a stream for sending while they still expect to receive data from the target of the CONNECT. stream. A proxy treats any error in the TCP connection, which includes receiving a TCP segment with the RST bit set, as a stream error of type H3CONNECTERROR; see Section 8. Correspondingly, if a proxy detects an error with the stream or the QUIC connection, it MUST close the TCP connection. If the underlying TCP implementation permits it, the proxy SHOULD send a TCP segment with the RST bit set. Not all of that guidance directly translates but I think it would be helpful to set some expectations for endpoints wrt how stream read or write states might change during the lifetime of a CONNECT-UDP request - especially in the cases where no stream data is being exchanged.
I took "FIN or RESET = done" as a given, but it's worth stating. Proxy behavior will likely be identical in both the graceful and abrupt closure cases.
Change:
devices from getting access to the network and potentially harming others. <del> Typically, solutions start with a specific component (called a root of trust) that is intended to provide trustworthy device identity and protected storage for measurements.  The system components perform a series of measurements that may be signed via functions provided by a root of trust, considered as Evidence about present system components, such as hardware, firmware, BIOS, software, etc. </del> <ins> Typically, a trustworthy solution starts with a specific component (sometimes referred to as a root of trust) that often provides trustworthy device identity, and performs a series of operations that enables trustworthiness appraisals for other components.  Such components perform operations that help determine the trustworthiness of yet other components, by collecting, protecting or signing measurements.  Measurements that have been signed by such components comprise Evidence that when evaluated either supports or refutes a claim of trustworthiness.  Measurements can describe a variety of attributes of system components, such as hardware, firmware, BIOS, software, etc. </ins> A device desiring access to a network.

Discussion:
Reworded sections containing root of trust leaving a single parenthetical that associates the term loosely with an attesting environment that is implicitly trusted.
It makes sense to remove the term 'root of trust' since the document doesn't define it. It might make sense to reference other industry specs that have relevant definitions such as NISTIR 8320A.
NAME apparently, this taks has no assignees. Do you want to do that?
OK, assign it to me.
Change:
The SNI encryption key is computed from the DH shared secret Z as follows: <del> The EncryptedSNI.encrypted_sni value is then computed by: </del> <ins> The EncryptedSNI.encrypted_sni value is then computed using the usual TLS 1.3 AEAD: Note: future extensions may end up reusing the server's ESNIKeyShare for other purposes within the same message (e.g., encrypting other values).  Those usages MUST have their own HKDF labels to avoid reuse. </ins> <del> [[OPEN ISSUE: This is a strawman construction.  We do want a nonce to avoid situations where the server somehow reuses a key, but exactly how we mix it in is TBD.  Maybe in both places?]] </del> <ins> [[OPEN ISSUE: If in future you were to reuse these keys for 0-RTT priming, then you would have to worry about potentially expanding twice of Z_extracted.  We should think about how to harmonize these.]] </ins> This value is placed in an "encrypted_server_name" extension.

Discussion:
You are mixing URL in. That would seem to be sufficient. From that you can generate the AEAD nonce and key as though this were record protection. We don't need another reason for people to complain about exposing the random number generator state to the network.
If servers choose to use the same ESNI and semi-static key, not generating and including a nonce could lead to nonce-reuse for 0-RTT data. We talked about just prohibiting this sort of key sharing for servers, though it's good to have a client-side defense against it.
Change:
can be fetched via a GET request.  The result of the GET request MUST be a JSON object whose "certificates" field is an array of strings, where each string is the URI of a certificate.  The <del> server SHOULD NOT include expired certificates. </del> <ins> server SHOULD NOT include expired or revoked certificates. </ins> 5.3.

Discussion:
editorial change
These LGTM as editorial. I note that the inclusion of "revoked" in URL is on the edge, but I think it was intended and could be merged as a result.
I did think the mentioned change might be an edge case, too, but came to the same conclusion. Happy to be of any help.
LGTM as well. Thanks NAME
Change:
Action RFC2434. TLS HandshakeType Registry: Future values are allocated via <del> Standards Action RFC2434. </del> <ins> Standards Action RFC2434.  IANA [SHALL update/has updated] this registry to rename item 4 from "NewSessionTicket" to "new_session_ticket". </ins> This document also uses a registry originally created in RFC4366. IANA has updated it to reference this document.  The registry and its

Discussion:
This is purely aesthetic, but apparently no one realizes the name is different, not even IANA, so we may as well go fix it. (I don't know how to write IANA considerations, so I've left it a TODO. But if you give me text, I'll update this PR to include it.) For consistency. At a glance, it seems most TLS implementations did not realize the HandshakeType value was actually named sessionticket and assumed it was named newsession_ticket anyway. Moreover, the IANA entry was named neither and actually named NewSessionTicket since RFC 4507's IANA considerations used the wrong name.
Change:
An encoder that receives an Increment field equal to zero, or one that increases the Known Received Count beyond what the encoder has sent MUST treat this as a connection error of type <del> "HTTP_QPACK_DECODER_STREAM_ERROR". </del> <ins> QPACK_DECODER_STREAM_ERROR. </ins> 4.5.

Discussion:
I noticed that the QPACK error codes still started with the HTTPQPACK prefix, while the HTTP document has shifted to H3 as the prefix. I shortened the QPACK prefix to simply "QPACK", though "H3QPACK" could work, too. Along the way, I noticed that backticks were sometimes, but not always, used when referring to the error code names. We haven't been in the HTTP document, so I reconciled them to not. Again, this could go the opposite way. I also noticed that the settings are "SETTINGSQPACK" except in the IANA registration where they're simply "QPACK". I didn't touch those, but am open to feedback on whether that's worth trimming/reconciling.
NAME I don't need your approval, but I kind of do need NAME
Well, you did ask :)
NAME could you review and potentially merge?
Do it. You don't need my approval to do something that is so self-evidently a good idea.QPACK_ prefix WFM
Change:
endpoint.  The connection ID is used by endpoints and the intermediaries that support them to ensure that each QUIC packet can be delivered to the correct instance of an endpoint.  At the <del> endpoint, the connection ID is used to identify which QUIC connection the packet is intended for. </del> <ins> endpoint, the connection ID is used to identify the QUIC connection for which the packet is intended. </ins> The connection ID is chosen by each endpoint using version-specific methods.  Packets for the same QUIC connection might use different

Discussion:
Issue raised by NAME via : OLD:/At the endpoint, the connection ID is used to identify which QUIC connection the packet is intended for./ NEW:/At the endpoint, the connection ID is used to identify the QUIC connection for which the packet is intended./
Sounds good. I'll do that too. I have read Version-Independent Properties of QUIC (-30) in the WGLC and think this is ready, I found 3 editorial comments that might need consideration after the WGLC: (i) I suggest the introduction for this spec starts abruptly. Is it worth considering one sentence top explain what QUIC is, in case someone read this document first? - One possible solution could be to move the text in section 3 to section 1? (To me, the section 3 text does not need to come after the Section 2 definitions.) (ii) Does this read better with /for/ moved within the sentence? OLD:/At the endpoint, the connection ID is used to identify which QUIC connection the packet is intended for./ NEW:/At the endpoint, the connection ID is used to identify the QUIC connection for which the packet is intended./ (iii) I see the desire to emphasise the “NOT”, but I query if this is correct usage of a RFC2119 keyword in Appendix A?: /The following statements are NOT guaranteed to be true for every QUIC version:/ Best wishes, Gorry
Change:
schemes like Prio in which the input-validation protocol is only run once per report, each aggregator only needs to store its aggregate share for each possible batch interval, along with the number of <del> times the aggregate share was used in a batch.  (The helper may store its aggregate shares in its encrypted state, thereby offloading this state to the leader.)  This is due to the requirement that the batch interval respect the boundaries defined by the DAP parameters.  (See batch-parameter-validation.) </del> <ins> times the aggregate share was used in a batch.  This is due to the requirement that the batch interval respect the boundaries defined by the DAP parameters.  (See batch-parameter-validation.) </ins> 6.

Discussion:
This is a follow-up to , removing a few dangling references to the helper state blob.
Change:
8.2. This document will request IANA to register the following entry in <ins> the "HTTP/3 Error Code" registry: 8.3. This document will request IANA to register the following entry in </ins> the "HTTP Field Name" registry: Capsule-Protocol

Discussion:
Borrowing text from H3. Also I don't think there is a 'FRAMEENCODINGERROR' defined anywhere.
Thanks! Approved pending some minor tweaks
Change:
2. <del> A CoAP Problem Details is a CoRAL document with the following </del> <ins> A CoRE Problem Details is a CoRAL document with the following </ins> elements: "type" (id) - The problem type.  This is a mandatory element.

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:
integrity is provided by the inner MAC (and signature depending on method). <del> The data rates in many IoT deployments are very limited.  Given that the application keys are protected as well as the long-term authentication keys they can often be used for years or even decades before the cryptographic limits are reached.  If the application keys established through EDHOC need to be renewed, the communicating parties can derive application keys with other labels or run EDHOC again. </del> Requirement for how to securely generate, validate, and process the ephemeral public keys depend on the elliptic curve.  For X25519 and X448, the requirements are defined in RFC7748.  For secp256r1,

Discussion:
Comment by Robert Moskowitz
I think the forward secrecy could use some more text. Right know we are using the definition according to the IETF security dictionary, but as the security dictionary states, a lot of different definitions is used. The draft that the KeyUpdate gives much better security than using a single key, but that the KeyUpdate method gives a lower security level than frequently running ephemeral diffie-hellman
Change:
examples throughout these sections assume the use of CoAP RFC7252, these REST interfaces can also be realized using HTTP RFC7230.  Only multicast discovery operations are not possible on HTTP, and Simple <del> Registration can not be executed as base attribute (which is </del> <ins> Registration can not be executed as the base attribute (which is </ins> mandatory for HTTP) can not be used there.  In all definitions in these sections, both CoAP response codes (with dot notation) and HTTP response codes (without dot notation) are shown.  An RD implementing

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:
the certificate URI does not yield one, then the client may initiate a new-certificate transaction to request one. <del> 6.7. </del> <ins> 6.8. </ins> To request that a certificate be revoked, the client sends a POST request to the ACME server's revoke-cert URI.  The body of the POST

Discussion:
What advantage does including the old key provide?
Having the new key sign over the field makes the hand-over mutual -- the old key blesses the new key by signing over the JWS and the new key accepts by signing over the thumbprint. Basically, the field is acting as an identifier for the registration for purposes of the new key's acceptance of the hand-over. Note that this is well-defined because the server is required to only have one registration for a given key-pair (it MUST return a 409/Conflict if there's an attempt to duplicate).
Account keys should change over time to improve security. We should have a way to change the key associated with an account with changing anything else about the account. Something liike: Post: /rotate-key { "key": { / JWK key / } } Note: The request should be signed with the old key. All authorizations should remain with the account. If there are any requests being validated then they should still use the old key (as specified by the oriignal authorization request.
Change:
function is performed by the DNS operator plus other entities who decide about the allowed contents of the zone. <ins> These terms are introduced in RFC3731 but not defined there. Instead, they are given in examples.  "For example, domain name 'example.com' has a superordinate relationship to host name ns1.example.com'."  "For example, host ns1.example1.com is a subordinate host of domain example1.com, but it is a not a subordinate host of domain example2.com."  (Quoted from RFC3731, Section 1.1.)  These terms are strictly ways of referring to the relationship standing of two domains where one is a subdomain of the other. </ins> 8. Most DNSSEC terms are defined in RFC4033, RFC4034, RFC4035, and

Discussion:
In June 2015, Joe Abley said: I think that "superordinate" and "subordinate" might be worth mentioning here, with reference to their definitions in EPP.
Added in URL
I think this is ok. Friendly amendment is to note that these are strictly ways of referring to the relationship standing of two domains where one is a subdomain of the other. (But I don't know that we need to do this, hence the approval.)
Change:
affects the direction attribute of the associated m= section on future calls to createOffer and createAnswer. <del> TODO: Write example showing how this might be used and how it affects offers/answers/reoffers.  Maybe something like: "sendonly" remote offer, setDirection("sendonly"), "inactive" answer, "sendonly" reoffer. </del> <ins> When creating offers, the transceiver direction is directly reflected in the output, even for reoffers.  When creating answers, the transceiver direction is intersected with the offered direction, as explained in the sec.generating-an-answer section below. </ins> 4.2.4.

Discussion:
Also, fixes problem where my previous change to explain the directional attribute for answers was accidentally applied to the offer section.
Not clear whether this should be an example, i.e., in the Examples section, or perhaps just an aside in the setDirection section.
Change:
(except when messages were corrupted in the network). <del> This alert was used in previous versions of TLS.  TLS 1.3 does not include compression and TLS 1.3 implementations MUST NOT send this alert when in TLS 1.3 mode.  This alert is always fatal. </del> Reception of a "handshake_failure" alert message indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available.  This alert is always fatal. <del> This alert was used in SSL 3.0 but not any version of TLS.  It MUST NOT be sent by compliant implementations.  This alert is always fatal. </del> A certificate was corrupt, contained signatures that did not verify correctly, etc.

Discussion:
Note: unRESERVEDing SHA-1 and DSA is intentional. The point is that that things which are RESERVED are totally forbidden. Because you can offer SHA-1, we need the code point. If we decide to make DSA MUSTNOT, then I'll mark it reserved and update the text.
On Saturday, October 03, 2015 04:42:44 pm ekr wrote: Agreed. Using the "RESERVED" notation before was a bit iffy and with this new refactoring it has to be changed now. Just need to make sure it's mentioned explicitly that it's restricted.