jiebi/CodeConvo huggingface dataset:
Change:
This alert was used in SSLv3 but not any version of TLS.  It MUST <del> NOT be sent by compliant implementations. </del> <ins> NOT be sent by compliant implementations.  This message is always fatal. </ins> A certificate was corrupt, contained signatures that did not

Discussion:
Expands on NAME improvements. The obsolete alerts were previously fatal and still are. Mark them as such. Also fix one of their names which is missing the "_RESERVED" in the descriptions list.
Change:
proactively issue the requested certificate and provide a URL for it in the "certificate" field of the order.  The server MUST, however, still list the completed authorizations in the "authorizations" <del> array, with the state "valid". </del> <ins> array. </ins> Once the client believes it has fulfilled the server's requirements, it should send a GET request to the order resource to obtain its

Discussion:
As discussed at IETF 97, this PR removes the "requirements" abstraction, and changes the "requirements" field in an application/order object to be an "authorizations" field. This is a replacement for .
Let's Encrypt tell me that they have had a few reports of buggy clients creating enough pending authorizations to saturate their rate limits, so they need a way for clients to clear these out. These clients are also not keeping around authorization URLs, so they can't just go them. My proposed solution would be to re-add the "authorizations" field to the account object, which got lost in the refactor in or so. Together with deactivation, enabling clients to enumerate authorization URLs would solve this problem. You could also envision a more direct solution, offering an endpoint that just deletes all pending authorizations for a client or client+identifier.
This is definitely too specific to these buggy clients. For the flow, the list of orders is sufficient. It's true that technically you can create authorizations through a separate, optional, flow. But Let's Encrypt has no plans to implement that flow, because other CAs have said they cannot / would not implement it, so Let's Encrypt implementing it would split the market. I'm inclined to say let's not complicate the protocol, and hypothetical clients that want to do the flow with some hypothetical server need to keep proper track of their authzs. Also, I think the particular issue with hitting limits for pending authzs can be solved in several ways without modifying the protocol.
If is merged, I would expect that a reasonable ACME server supporting new-authz would return an exiting authz, instead of giving a rate limit error. Or return existing authz from the beginning.
Closing as a result of WG decision at IETF 98
Change:
this connection (thus preventing replay of client CertificateVerify messages).  This field SHALL be zero length unless used for the post-handshake authentication exchanges <del> described in post-handshake-authentication. </del> <ins> described in post-handshake-authentication.  When requesting post- handshake authentication, the server SHOULD make the context unpredictable to the client (e.g., by randomly generating it) in order to prevent an attacker who has temporary access to the client's private key from pre-computing valid CertificateVerify messages. </ins> A set of extensions describing the parameters of the certificate being requested.  The "signature_algorithms" extension MUST be

Discussion:
be unpredictable in order to prevent pre-computation of CertificateVerify. Maybe this should actually be a MUST?
Note: an attacker can of course forge a complete handshake but maybe for some quirk of the environment that's not as good.
Change:
the definition of application_secret.) The secret of any other node in the tree is derived from its parent's <del> secret using a call to Derive-App-Secret. </del> <ins> secret using a call to DeriveAppSecret. </ins> If N is a node index in the AS Tree then the secrets of the children of N are defined to be:

Discussion:
In , we changed from using HKDF to using the KDF from HPKE, which I thought removed the need for the ciphersuite to specify a hash function. As a result, ciphersuites no longer needed to specify a hash. However, the transcript computations still have a raw invocation, not a KDF invocation. So we need to either: Change the transcript hash computations to use the KDF, or Clarify that ciphersuites still specify a hash function (as before)
What about the call in the and the "hashes" for ?
Our HPKE dependency provides a perfectly usable KDF. We should just use that instead of nailing a dependency to HKDF. This will mainly be a matter of changing and calls to the corresponding calls on the HPKE KDF.
I can't wait to see the implementations.
Thanks for the enthusiasm, but I don't think this is a spec issue :)
Change:
In this model, the Origin and Issuer are operated by the same entity, separate from the Attester, as shown in the figure below.  The Issuer <del> accepts token requests that come from trusted Attesters.  Depending on the issuance protocol, the Attester may relay these requests between Client and Issuer over an authenticated channel, or trust may be established in some other manner. </del> <ins> accepts token requests that come from trusted Attesters.  Since the Attester and Issuer are separate entities, the Attester must authenticate itself to the Issuer.  In settings where the Attester is a Client-trusted service, one way Attesters can authenticate to Issuers is via mutually-authenticated TLS.  However, alernative authentication mechanisms are possible.  This arrangement is shown below. </ins> This model is useful for Origins that require Client-identifying attestation, e.g., through the use of application-layer account

Discussion:
Split attesters and issuers are not required for the basic issuance protocol, but we should explain (in a sentence or so) that if you are using a split attester, the client sends the request to the attester, and the attester forwards the request to the issuer if it accepts the client.
For better clarity and consistency, I recommend adding a sequence diagram depicting this model considering the sequence diagrams that outline other models.
Agreed. This would be a good thing to include. I'll take this and add it.
In a split attester/issuer scenario, the issuer needs to authenticate the attester in some way (e.g., TLS client cert). In a combined attester/issuer scenario, the actual protocol might be something proprietary (or covered by an as-yet-unwritten spec) that extends the base issuance protocol, e.g., adding an attestation header, user login cookie, or adding extra challenge/response rounds to confirm identity. If these issues are "in scope" then they should be defined here. If they are "out of scope" then it would be helpful context to reader to describe what is expected to be handled by a proprietary extension.
NAME we discuss these things in the architecture document where deployment models are discussed. But we should mention the impact that different deployment models have on the basic issuance protocol in the -protocol spec.
Change:
containing a random payload on the path to be validated. An endpoint MAY send multiple PATH_CHALLENGE frames to guard against <del> packet loss, however an endpoint SHOULD NOT send multiple </del> <ins> packet loss.  However, an endpoint SHOULD NOT send multiple </ins> PATH_CHALLENGE frames in a single packet.  An endpoint SHOULD NOT send a PATH_CHALLENGE more frequently than it would an Initial packet, ensuring that connection migration is no more load on a new

Discussion:
I really appreciate all of these PRs. It's easy to miss these things with larger changes.
Change:
4.2.2. <del> The "primary" section records a single URL identifying the primary URL of the bundle.  The URL MUST refer to a resource with representations contained in the bundle itself. 4.2.3. </del> The "manifest" section records a single URL identifying the manifest of the bundle.  The URL MUST refer to a resource with representations contained in the bundle itself.

Discussion:
This PR removes the primary URL section. The motivation is to factor the "core" Web Bundles specification to include just the minimal amount needed to support cases like subresource loading. This and other removed sections can be defined in other documents in the future.
The subresource loading doesn't need a primary URL, but I think "Navigate to Bundle" use case still needs it. URL NAME NAME Please correct me if I am wrong. I'm assuming "Navigate to Bundle" uses a primary URL as a main resource URL.
That's correct. For a bundle to be navigable into, it needs to be possible to specify its main resource URL.
Yes, to open the web bundle file in the browser (eg: Drag and drop) we need either the primary URL or the manifest's . So, we need to keep either as an optional section.
The idea of this PR is that a primary URL could be defined in a separate section. However, it is outside the scope of the "core" bundle specification to define this section.
Thanks for making a PR! Could we see a path to having other document more clearly? Since we need a primary URL defined somewhere, it might be difficult to remove a primary URL section without a clear path how a primary URL is defined.
(Just in case if someone missed it) It seems this PR is one of agenda points at IETF 111 Wpack. URL
NAME : I just opened URL to discuss the possibility of creating an extension of the spec as a separate document.
LGTM (just for record). Thanks for working on this. Hello WPACK, My name is Felipe Erias. I am working on Web bundles at Igalia together with Dan Ehrenberg. I have just created several PRs at wpack-wg/bundled-responses and I am writing this email to request the addition of a point to discuss them to the agenda for the group's upcoming meeting at the end of July. These PRs address the removal of the primary URL section, the manifest section, and content negotiation. Most of this has been adapted from previous work by Dan on the WICG/webpackage repo. The overarching goal is to simplify the "core" Web Bundles specification so it includes just the minimal amount needed to support use cases like subresource loading. The removed sections may be defined in other documents in the future. These are the PRs: URL URL URL Best, Felipe
Change:
in I-D.ietf-tls-negotiated-ff-dhe.  Values 0x01FC through 0x01FF are reserved for private use. <del> Values within "obsolete_RESERVED" ranges were used in previous versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 implementations.  The obsolete curves have various known/theoretical weaknesses or have had very little usage, in some cases only due to unintentional server configuration issues.  They are no longer considered appropriate for general use and should be assumed to be potentially unsafe.  The set of curves specified here is sufficient for interoperability with all currently deployed and properly configured TLS implementations. </del> Items in named_curve_list are ordered according to the client's preferences (most preferred choice first).

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.
Change:
The context used for the derivation of the "exported_value" MAY be empty while each application SHOULD provide a unique label as an <del> input of the HKDF-Expand-Label for each use case.  This is to prevent </del> <ins> input of the ExpandWithLabel for each use case.  This is to prevent </ins> two exported outputs from being generated with the same values and used for different functionalities.

Discussion:
In , we changed from using HKDF to using the KDF from HPKE, which I thought removed the need for the ciphersuite to specify a hash function. As a result, ciphersuites no longer needed to specify a hash. However, the transcript computations still have a raw invocation, not a KDF invocation. So we need to either: Change the transcript hash computations to use the KDF, or Clarify that ciphersuites still specify a hash function (as before)
What about the call in the and the "hashes" for ?
Our HPKE dependency provides a perfectly usable KDF. We should just use that instead of nailing a dependency to HKDF. This will mainly be a matter of changing and calls to the corresponding calls on the HPKE KDF.
I can't wait to see the implementations.
Thanks for the enthusiasm, but I don't think this is a spec issue :)
Change:
Only servers can push; if a server receives a client-initiated push stream, this MUST be treated as a connection error of type <del> HTTP_WRONG_STREAM_DIRECTION. </del> <ins> HTTP_STREAM_CREATION_ERROR. </ins> Each Push ID MUST only be used once in a push stream header.  If a push stream header includes a Push ID that was used in another push

Discussion:
There are presently several kinds of very similar error when creating streams: HTTPUNKNOWNSTREAMTYPE MAY be used to tell a peer to STOPSENDING on a stream type that is unknown by the local peer. It is not a connection error. HTTPWRONGSTREAMCOUNT MUST be used if a peer tries to open more than one critical stream (control, QPACK). Connection error. HTTPWRONGSTREAMDIRECTION MUST be used if a client tries to open a push stream. More generally this could be used if a peer attempts to open a stream type that is not allowed to, but push is the only example today. Connection error. The suggestion is to rationalize these into a single error code - HTTPSTREAMCREATIONERROR - that can be used in STOPSENDING or CLOSECONNECTION. The impact of merging COUNT and DIRECTION is minimal because implementations fundamentally have to open streams correctly in order to interop. PS. The eagle eyes will notice I omitted the HTTPDUPLICATE_PUSH creation error. This is on the chopping block in . I class it differently because it is about parsing information after the stream type.
Should a client respond with STREAMCREATIONERROR when it sees the server opening a bidirectional stream? At the moment the designated error code is HTTPGENERALPROTOCOLERROR, but STREAMCREATIONERROR might be a better fit. Or if we are not going to use STREAMCREATIONERROR for server-initiated bidirectional streams, I think we should better rename it to UNIDIRECTIONALSTREAMCREATIONERROR to avoid confusion.
This relates to some earlier discussion on URL and its now-merged PR URL We only recently added text to specify the use of HTTPGENERALPROTOCOLERROR in this case, I think it fits to modify this to STREAMCREATION_ERROR.
Changed in URL
Change:
Specify a Local Endpoint using a STUN server: <ins> 6.1.4. </ins> Specify a Local Endpoint using an Any-Source Multicast group to join on a named local interface: Source-Specific Multicast requires setting both a Local and Remote Endpoint: <ins> One common pattern for multicast is to both send and receive multicast.  For such cases, an application can set up both a Listener and a Connection.  The Listener is only used to accept Connections that receive inbound multicast.  The initiated Connection is only used to send multicast. </ins> 6.2. A Preconnection Object holds properties reflecting the application's

Discussion:
I realise I'm late reviewing this, but this approach seems pretty cumbersome. Why do we need two connections, once send only and one receive only, rather than a single bidirectional connection? It also seems cumbersome to implement: both objects will be bound to the same port, and so will receive the multicast packets once the group has been joined. The send-only must then filter out those received packets?
In the multicast endpoint section, we should have explicit examples for patterns of ASM and SSM. Listen(multicast address, port, interface) Get a connection from a specific remote endpoint Initiate a connection back to talk to that endpoint, etc
We should mention the IGMP joining in Implementation, etc too
If we haven't done so, should note than one process may receive from the same address with SO_REUSEADDR so that every incoming multicast or broadcast UDP datagram destined to the shared port is delivered to all.
NAME I think the other bits about reuse address belong in implementation, filed
See my comment on – this approach seems cumbersome
For SSM, -> send only, -> receive only, makes sense. But for ASM, I'm increasingly thinking that we also want -> multicast peer that can both send and receive on a single local port: you want sender and receiver to be bound to the same local address/port pair.
I feel uncomfortable here. I have been persuaded we should add ASM Multicast. I suggest try a PR and see if this is simple and helpful?
Interim: waiting on NAME
CSP to propose a PR to see if this needs to be taken in a different direction.
Change:
7.3.3.1. One important feature of MLS is that all Members know which other <del> clients are in the group at all times.  If all Members of the group </del> <ins> members are in the group at all times.  If all Members of the group </ins> and the Authentication Service are honest, no parties other than the members of the current group can read and write messages protected by the protocol for that Group. <del> Beware though, the link between the cryptographic identity of the client and the real identity of the End User is important.  Details about how to verify the identity of a client depend on the MLS Credential type used.  For example, cryptographic verification of </del> <ins> Details about how to verify the identity of a client depend on the MLS Credential type used.  For example, cryptographic verification of </ins> credentials can be largely performed autonomously on the clients for the "x509" Credential type.  In contrast, when MLS clients use the "basic" Credential type, a larger degree of trust must be placed in a

Discussion:
The Section has three recommendations, but the discussion rambles. The proposed text places topics related to each recommendation before that recommendation.
Thanks!
Comment by NAME Why allow this in the MLS protocol? How can this "typically" be the case of some of the biggest messaging infrastructures? Clearly those don't run the MLS protocol? Perhaps you meant to compare a similar function to the AS in other messaging protocols? That is, I would clarify what is the issue, what is possible in MLS and how it compares to non-MLS existing deployments.
At a high level, MLS was designed to be agnostic about the authentication design, so I don't think there's much normative for MLS to say here. With that said, it seems to me that there are two practices here: A centralized/private authority. As the text says, this is very common and seems like a fairly natural design, whether we like it or not. That authority generating keys rather than signing them. That seems bad, and I guess we could discourage it, but it can't be enforceably prohibited
That was probably meant to be a comparison, yes, but this entire block has been removed through the multiple changes already made anyway. The important part was to describe things as ekr suggested which is already the case and there is already a recommendation to not design a system which generates the keys in the section about the AS.
Change:
processed.  An endpoint MUST NOT include delays that is does not control when populating the Ack Delay field in an ACK frame. <del> An endpoint MUST NOT excessively delay acknowledgements of ack- eliciting packets.  An endpoint commits to a maximum delay using the max_ack_delay transport parameter; see transport-parameter- definitions.  max_ack_delay declares an explicit contract: an endpoint promises to never delay acknowledgments of an ack-eliciting packet by more than the indicated value.  If it does, any excess accrues to the RTT estimate and could result in delayed retransmissions from the peer.  For Initial and Handshake packets, a max_ack_delay of 0 is used. </del> 13.2.6. ACK frames MUST only be carried in a packet that has the same packet

Discussion:
Also removes obsolete text about acknowledging CRYPTO frames quickly, now that Initial and Handshake packet spaces have a maxackdelay of 0.
Sorry I'm late here but I think it would still be good to mention that congestion control usually is supposed to work on a RTT granularity and if you send less ACKs than one per RTT that can have an impact on cc. I don't think this has to be a normative requirement given you have normative requirements on maxackdelay and a reasonable default value but it would still be good to mention this dependency as cc is done on sender and ACKing on receiver and therefore it might not always that obvious.
The spec gives no reason (that I can see) as to why an ACK frame must be sent at least once per round trip (assuming there are ack-eliciting packets to acknowledge), effectively overwriting the ACK delay logic when the RTT is very small. If the RTT is smaller than the platform's timer granularity, this isn't really even possible. I propose to remove this requirement. If the WG instead feels that we should keep this requirement, then there should be a reasoning for it; and probably an update to the PTO calculation as well.
As I commented on the PR that this came up in, given we have an explicit maxackdelay that's now communicated, removing the 1 ACK per RTT requirement seems wise. TCP has no such recommendation and I'm unaware of any indications or proposals that it should have such a property.
NAME point that the RTT can be smaller than the platform's granularity is a good one. I agree that this text ought to be removed.
This is changing text in a SHOULD statement, so I believe it should be marked as design.
LGTM