Question: extension.  It MUST NOT save the "retry_config" value in EncryptedExtensions. <del> [[OPEN ISSUE: Depending on what we do for issue#450, it may be appropriate to change the client behavior if the HRR extension is present.]] </del> Offering a GREASE extension is not considered offering an encrypted ClientHello for purposes of requirements in real-ech.  In particular, the client MAY offer to resume sessions established without ECH.

But that is just how it is. We get to choose between that leakage and a known large amount of bustage.
This solution admits a straightforward, active distinguisher: just intercept CH1, respond with a fake HRR, and look at CH2. It's true that we "give up" on making HRR not stick out in . However, one of the design goals there is to prevent active attacks that trigger the HRR code path when it otherwise would not have happened. What we give up on is ensuring "don't stick out" when HRR is inevitable for the given client and server.
Ah, are you saying that this conflicts with (and thus would have to be removed if is merged)?
I believe resolves the same "OPEN ISSUE", yes.
I just noticed this as I was pondering our various HRR issues. RFC8446, section 4.1.2 says: URL The "and present in the HelloRetryRequest" portion is fun. In RFC8446 as written, we're not allowed to change the extension on the second ClientHello unless the server sent in HelloRetryRequest, which it doesn't. With the protocol as-is, it seems we'll at least need some text to deal with the contradiction. The impact is practice is thankfully limited. If the servers does not enforce consistency between the two ClientHellos, it doesn't matter. (They're not required to, but they're not explicitly forbidden from it either, and a stateless server may need to enforce some minimum consistency to avoid getting into a broken state.) If a server does, ECH's behavior on HRR will break it. Such a server is supposed to handshake with ClientHelloOuter, so it just affects the retry flow. That's maybe okay, but mildly annoying. Administrators using server software that checks need to know to first upgrade to a version that doesn't check before trying to deploy ECH. We can also add an ECH extension to HRR. Then, on ECH-reject + HRR, the server perhaps wouldn't send the extension and the client would be required to replay the extension. This is a waste in many ways, but would work. This would break don't stick out, but some threat models, don't stick out with HRR is hopeless anyway.


Question: extension.  It MUST NOT save the "retry_config" value in EncryptedExtensions. <del> [[OPEN ISSUE: Depending on what we do for issue#450, it may be appropriate to change the client behavior if the HRR extension is present.]] </del> Offering a GREASE extension is not considered offering an encrypted ClientHello for purposes of requirements in real-ech.  In particular, the client MAY offer to resume sessions established without ECH.

(See URL) It would also be weirdly asymmetric between ECH and SH. That said, this constraint is also pretty obnoxious. For instance, currently adds a new padding extension codepoint, because the old one isn't defined for other messages. However, the RFC8446 allowance only works for the existing padding code point, so you don't want to send any other code points in ClientHello, lest the server force you to keep it unchanged in ClientHello2. So maybe we should confirm no servers did the fully strict check and undo that constraint? (Although, for , I personally favor the padding message strategy anyway.)
NAME points out the Go implementation does check CH1 and CH2 consistency. Fortunately, it only checks known extensions, so it's still compatible with the ECH draft. URL Checking only know extensions is basically saying we should strike "and present in the HelloRetryRequest" in rfc8446bis and make sure everyone knows not to check this.
I don't think we can just strike this text because the point of that text was that you couldn't like change your KeyShares if the HRR didn't tell you to. But I agree we can sharpen this in some sensible way.
I figured that case was covered by "defined in the future", which I'm not proposing we delete. keyshare isn't defined in the future, so it falls under existing rules. The existing rules (bullet points over that one) only let you change keyshare "[i]f a "key_share" extension was supplied in the HelloRetryRequest". But perhaps that's a little roundabout. The rules I'm thinking of are (changes emphasized): Each extension gets to define how it reacts to HRR. It typically is sensitive the corresponding HRR extension, but doesn't have to be. RFC8446(bis) defines the rules for all existing extensions. Future extensions define their own rules. (And probably if they don't say anything, we assume they don't get to change.) As a server, you can make assumptions based on the rules for extensions you know about. You have to tolerate random changes in extensions you don't know about, because you don't know their rules.* I'm running a probe on a bunch of servers to see how they react to changes in cipher suites, curves, and a random extension.


Question: extension.  It MUST NOT save the "retry_config" value in EncryptedExtensions. <del> [[OPEN ISSUE: Depending on what we do for issue#450, it may be appropriate to change the client behavior if the HRR extension is present.]] </del> Offering a GREASE extension is not considered offering an encrypted ClientHello for purposes of requirements in real-ech.  In particular, the client MAY offer to resume sessions established without ECH.

It seems most don't notice. Some (I'm guessing Go) notice cipher suites and curves. None notice a random extension. That suggests the change will be compatible.
I spoke too soon. LibreSSL breaks if you change an extension they don't recognize. :-(
So draft-09 isn't tied up with this, I've uploaded URL as a bandaid for the potential compatibility issue. (I say potential because it's only a problem if the server checks unknown extensions and has different enough key share preferences from the client that it needs HRR. HRR is pretty rare, so it may not actually be an issue. For Chrome, at least, I don't think the particular servers I found actually trigger HRR. But it is still a risk for clients or servers with different configurations.)


Question: clients that they are behind a captive-portal enforcement device and how to contact an API for more information. <ins> This document replaces RFC 7710 RFC7710. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Note that I do need you both to confirm that you have fulfilled IPR obligations.
Thank you!


Question: renders 5-tuple based filtering insufficient and requires more state to be maintained by DDoS defense systems.  For the common case of NAT rebinding, DDoS defense systems can detect a change in the client's <del> endpoint address by linking flows based on the first 8 bytes of the server's connection IDs, provided the server is using at least 8- bytes-long connection IDs.  QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID and necessitates that connection ID-aware DDoS defense system must have the same information about connection IDs as the load balancer I-D.ietf-quic-load-balancers.  This may be complicated where mitigation and load balancing environments are logically separate. </del> <ins> endpoint address by linking flows based on the server's connection IDs.  QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID. </ins> It is questionable whether connection migrations must be supported during a DDoS attack.  If the connection migration is not visible to

Merged... with the neurons I have left on 22 December, this seems broadly true. I'm not sure we should be too prescriptive about load balancing in this doc, though -- in part because I suspect the challenge of handling DDoS attacks using QUIC traffic will lead to divergent innovation in the LB space in the near term...
So if the 5-tuple changes because of NAT, the connection ID might actually not change. So in case of DDoS you might want to look at the connection ID to at cover those cases. For DDoS you usually don't need a hard guarantee to track all flows (if you block a flow incorrectly, it has to reconnect), but where you can track the flow when the 5-tuple changes, it might actually help. That is what this paragraph is/was about.
"QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID and necessitate that connection ID aware DDoS defense system must have the same information about connection IDs as the load balancer {{?I-D.ietf-quic-load-balancers}}. This may be complicated where mitigation and load balancing environments are logically separate." This is insufficient. Even the load balancer is only able to identify the end server, not the connection.
On a related note, the suggestion to use the "first 8 bytes" of a server's connection ID is somewhat strange. Why not observe the CIDL it's using in long headers, or just have common configuration?
How about if we just remove any wording about load balancers here? Like this maybe:
On the 8 bytes: I actually not sure where this comes from, however, I assume that the thinking was that using the first 8 bytes might be good enough to avoid collisions if you don't know the connection ID length. But I guess we can remove it or add some more explanation... any thoughts?
If you read the Retry Services section of QUIC-LB, you'll see that there is no dependence on the Connection ID encoding at all. It is a common format for Retry Tokens that allows servers to (at a minimum) extract the original CIDs necessary for verification. Certainly, no device should drop packets simply because the CID has changed, which is maybe what you're trying to say here? But I'm not sure that this is a DDoS thing.


Question: renders 5-tuple based filtering insufficient and requires more state to be maintained by DDoS defense systems.  For the common case of NAT rebinding, DDoS defense systems can detect a change in the client's <del> endpoint address by linking flows based on the first 8 bytes of the server's connection IDs, provided the server is using at least 8- bytes-long connection IDs.  QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID and necessitates that connection ID-aware DDoS defense system must have the same information about connection IDs as the load balancer I-D.ietf-quic-load-balancers.  This may be complicated where mitigation and load balancing environments are logically separate. </del> <ins> endpoint address by linking flows based on the server's connection IDs.  QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID. </ins> It is questionable whether connection migrations must be supported during a DDoS attack.  If the connection migration is not visible to

The point is when a DDoS attack is on-going you want to make sure that on-going connections keep running while new connections are handled more carefully. So you have to be flow aware. However, maybe it's acceptable if connectivity breaks during a DDoS when the 5 tuple changes...? Otherwise you would need to be CID aware.
This PR removes the problems I cited in the issue. Ship it. I wonder if we should hit the point in the last sentence a little harder. If you want to support connection migration, there's nothing you can do in this space except the Retry Service stuff in QUIC-LB, is there?


Question: is represented as an encoded UncompressedPointRepresentation struct, as defined in RFC8446. <ins> 5.1.2. The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for signatures in FramedContentAuthData and the tree signatures.  It MUST be the same as the signature algorithm specified in the credentials in the leaves of the tree (including the leaf node information in KeyPackages used to add new members). </ins> The signatures used in this document are encoded as specified in RFC8446.  In particular, ECDSA signatures are DER-encoded and EdDSA signatures are defined as the concatenation of "r" and "s" as

As discussed in the virtual interim 2022-12-16, it is possible that extensions might be tempted to re-use HPKE public keys created for MLS. Even within MLS, we have two different public-key encryption cases, Welcome and Commit (though these currently use different keys). Currently, for Commit encryption, the HPKE parameter is set to the group context. The content of is actually undefined for Welcome encryption (!) This PR makes the following changes: Define general and functions that populte the HPKE parameter with an encoded label and context Apply these to Commit and Welcome encryption: Commit: label="UpdatePathNode", context= Welcome: label="Welcome", context= Add an IANA registry of public-key encryption labels (as for signing) There is also a bit of reorganization of the Ciphersuites section to split it into three subsections.
Note that any previous analysis of MLS had to take this particular reuse into account. This can't be the case for any arbitrary extensions reusing the key. So if MLS uses an extension that reuses the key, none of the existing analysis applies, which is a much bigger issue. This said, this reuse did decrease security -- it weakened FS in that a joiner had to hold on to their HPKE leaf key, which also allowed to decrypt the init secret from the welcome message, long after joining.
I think this captures what we discussed during the interim. FWIW, I'm wondering if we didn't have a domain separation issue in the past when we only had one HPKE public key in KeyPackages and used it for both the Welcome subsequently for UpdatePath as well. Either way, I think this is a good defense-in-depth mechanism.


Question: implementation should store the properties in storage common to all protocols, and notify all protocol instances in the Protocol Stack whenever the properties have been modified by the application.  For <del> protocol-specfic properties, such as the User Timeout that applies to TCP, the Transport Services implementation only needs to update the relevant protocol instance. </del> <ins> Protocol-specific Properties, such as the User Timeout that applies to TCP, the Transport Services implementation only needs to update the relevant protocol instance. </ins> If an error is encountered in setting a property (for example, if the application tries to set a TCP-specific property on a Connection that

We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.


Question: Endpoints MUST NOT send this extension in a TLS connection that does not use QUIC (such as the use of TLS with TCP defined in TLS13).  A <del> fatal unsupported_extension alert MUST be sent if this extension is received when the transport is not QUIC. </del> <ins> fatal unsupported_extension alert MUST be sent by an implementation that supports this extension if the extension is received when the transport is not QUIC. </ins> 8.3.

No point in levying requirements on them.
Section 8.2 says: However, this directly contradicts TLS 1.3 URL, which says: In order to say this, this document would need to Update 8446, and even then it doesn't make sense because the presumptive point of this rule is to detect attempts to negotiate QUIC with non-QUIC TLS endpoints, which don't need to conform to this RFC (and may predate it).
I don't think QUIC can tell anyone what do with regard to any protocol that is not QUIC. And since QUIC v1 carries its own TLS record wrapping it makes even less sense.
I agree with the problem statement, however I wonder if this opens a session ticket obtained using TLS13-over-TCP to be used in QUIC. Is that what we want?
NAME why would this text have an impact on that? Couldn't I negotiate TLS 1.3 over TCP w/o extension and then send the resume over QUIC w/ extension?
The point here is to insist on the alert if the extension is understood. This wasn't intended to supersede 8446.
NAME My bad. I was confused with the earlier versions of the QUIC-TLS draft that had the transport_parameters extension in the session tickets.
NAME I think you could phrase that, but is it useful, given that we can't rely on it?
Probably not. I'm OK with culling the text.
This might not be possible if a cloud load balancer only forwards QUIC with TLS and terminates TLS otherwise.


Question: Signature = I2OSP(R, n) | I2OSP(S, n) where n = ceiling(key_length / 8) <del> 9.2.1. </del> <ins> 9.1.1. </ins> On of the issues that needs to be discussed is substitution attacks. There are two different things that can potentially be substituted in

MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).


Question: "key_share", "pre_shared_key", "psk_key_exchange_modes", "early_data", "cookie", "supported_versions", "certificate_authorities", "oid_filters", "post_handshake_auth", <del> and "signature_algorithms_certs", extensions with the values </del> <ins> and "signature_algorithms_cert", extensions with the values </ins> defined in this document and the Recommended value of "Yes". IANA [SHALL update/has updated] this registry to include a "TLS

the type is called signaturealgorithmscert (singular) everywhere, not signaturealgorithmscerts (plural)


Question: and might be required to be a quoted-string if the base64url string includes "=" characters.  This challenge value MUST be unique for every 401 HTTP response to prevent replay attacks. <del> This attribute is required for all challenges. </del> <ins> This parameter is required for all challenges. </ins> "token-key", which contains a base64url encoding of the public key for use with the issuance protocol indicated by the challenge.

The document refers to authentication scheme attributes throughout; the term from HTTP is 'parameters'. Also, both the challenge and credentials definitions should say what to do with unrecognised parameters.


Question: The sending endpoint SHALL write the Code of the original CoAP message into the plaintext of the COSE object (see plaintext).  After that, the sending endpoint writes an Outer Code to the OSCORE <del> message.  The Outer Code SHALL be set to 0.02 (POST) or 0.05 (FETCH) for requests.  For non-Observe requests the client SHALL set the Outer Code to 0.02 (POST).  For responses, the sending endpoint SHALL respond with Outer Code 2.04 (Changed) to 0.02 (POST) requests, and with Outer Code 2.05 (Content) to 0.05 (FETCH) requests.  Using FETCH with Observe allows OSCORE to be compliant with the Observe processing in OSCORE-unaware intermediaries.  The choice of POST and FETCH RFC8132 allows all OSCORE messages to have payload. The receiving endpoint SHALL discard the Outer Code in the OSCORE message and write the Code of the COSE object plaintext (plaintext) into the decrypted CoAP message. </del> <ins> message.  With one exeception (see observe-option-processing) the Outer Code SHALL by default be set to 0.02 (POST) for requests and to 2.04 (Changed) for responses.  The receiving endpoint SHALL discard the Outer Code in the OSCORE message and write the Code of the COSE object plaintext (plaintext) into the decrypted CoAP message. </ins> The other currently defined CoAP Header fields are Unprotected (Class U).  The sending endpoint SHALL write all other header fields of the

This PR should (hopefully) conclude the main rewrite of Observe which was triggered by the security analysis and additional reviews of Observe. It should (hopefully) now be clear what part of the Observe related processing can be omitted in case Observe is not supported or in case intermediaries are not used. A new appendix E is covering the latter case.


Question: has received this parameter SHOULD NOT send an HTTP message header that exceeds the indicated size, as the peer will likely refuse to process it.  However, an HTTP message can traverse one or more <del> intermediaries (see Section 3.7 of SEMANTICS) before reaching the origin server.  Because this limit is applied separately by each </del> <ins> intermediaries before reaching the origin server; see Section 3.7 of SEMANTICS.  Because this limit is applied separately by each </ins> implementation which processes the message, messages below this limit are not guaranteed to be accepted.

Fixes several nits from the gen-art review, which basically all come down to defining terms appropriately and/or referencing their definitions. modifies definition of "stream" and "stream error"; pulls in more terms from SEMANTICS references SEMANTICS for definition of fields rewords to avoid the term "hop" and describes intermediation more explicitly rewords to avoid saying "not possible" and copies language from SEMANTICS advising against retries updates reference to definition of CONNECT in SEMANTICS. NAME your review would be appreciated.
In the HTTP genart review, NAME writes:
Yes, CONNECT only supports TCP, and there's no short-term plan to change that. There is separate relevant work such as but I don't think we need to change anything in the draft here - it pretty clearly mentions TCP so I don't see any ambiguity.
This question should be addressed by the definition of CONNECT the spec is referring to. It's worth double-checking the references in that section, though; it points to HTTP11, when I think there should be a definition in SEMANTICS.
In the HTTP genart review, NAME writes:
Presumably a reference into SEMANTICS; I'll look for the right section to point to.
In the HTTP genart review, NAME writes:
In the HTTP genart review, NAME writes:
In the HTTP genart review, NAME writes: "HTTP/3 stream". Perhaps it's worth defining "HTTP/3 stream" explicitly, in analogy to "HTTP/3 connection". Perhaps it's worth defining "message", too (this is only an HTTP concept, correct?). The document should make sure it clearly distinguishes terms and concept of QUIC vs. of HTTP/3 in all cases. In particular, what is the relationship between HTTP/3 frames and QUIC frames? It's important to make their difference and relationship explicit, as the document uses several other terms interchangeably between HTTP/3 and QUIC, like "connection" and perhaps "stream".
A few minor suggestions, but this is a good change.This looks good to me, thanks!


Question: provisional value 0xff020000, which might change with each edition of this document. <del> The salt used to derive Initial keys in Sec 5.2 of RFC9001 changes to </del> <ins> The salt used to derive Initial keys in Section 5.2 of QUIC-TLS changes to: </ins> <del> The labels used in RFC9001 to derive packet protection keys (Sec 5.1), header protection keys (Sec 5.4), Retry Integrity Tag keys (Sec 5.8), and key updates (Sec 6.1) change from "quic key" to </del> <ins> The labels used in QUIC-TLS to derive packet protection keys (Section Section 5.1 of QUIC-TLS), header protection keys (Section Section 5.4 of QUIC-TLS), Retry Integrity Tag keys (Section Section 5.8 of QUIC-TLS), and key updates (Section Section 6.1 of QUIC-TLS) change from "quic key" to </ins> "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku", to meet the <del> guidance for new versions in Section 9.6 of that document. </del> <ins> guidance for new versions in Section Section 9.6 of QUIC-TLS of that document. </ins> <del> The key and nonce used for the Retry Integrity Tag (Sec 5.8 of RFC9001) change to: </del> <ins> The key and nonce used for the Retry Integrity Tag (Section 5.8 of QUIC-TLS) change to: </ins> 4.

This uses kramdown tricks to make real links for the section references to RFC 9001 and uses a nicer label for those.


Question: Regular expression tests can be applied to "string" values only. <del> The value of the first operand ("containable") of a "contain-expr" is compared to every single element of the RHS "container".  In case of a match a selection occurs.  Containment tests -- like comparisons -- are restricted to primitive values.  So even if a structured "containable" value is equal to a certain structured value in "container", no selection is done. The value of the second operand ("container") of a "contain-expr" needs to be resolved to an array.  Otherwise nothing is selected. </del> The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least tightly).

From the meeting at IETF 112 ([1]): Consensus: 'in' won't be used, but it will be easy to add later if there's real demand [1] URL
Good eyes. Thanks!
Yes, we agreed to remove the 'in' operator as some kind of syntactic sugar. thanks
Thanks! I pushed a small commit removing an "in" example.


Question: Each endpoint advertises its own idle timeout to its peer.  An endpoint restarts any timer it maintains when a packet from its peer is received and processed successfully.  The timer is also restarted <del> when sending a packet containing frames other than ACK or PADDING (an ack-eliciting packet; see QUIC-RECOVERY), but only if no other ack- eliciting packets have been sent since last receiving a packet. Restarting when sending packets ensures that connections do not prematurely time out when initiating new activity. </del> <ins> when sending an ack-eliciting packet (see QUIC-RECOVERY), but only if no other ack-eliciting packets have been sent since last receiving a packet.  Restarting when sending packets ensures that connections do not prematurely time out when initiating new activity. </ins> The value for an idle timeout can be asymmetric.  The value advertised by an endpoint is only used to determine whether the

At the moment, we state that a QUIC packet that contains frames other than ACK and PADDING (), but I wonder if that is true for CONNECTIONCLOSE frame. A CONNECTIONCLOSE frame never elicits an acknowledgment. IIUC, it is not meant to be governed by the congestion controller. Considering the aspects, I think we should add CONNECTION_CLOSE to the list of non-ACK-eliciting frames.
That also ensures the congestion controller never inadvertently blocks sending a CONNECTIONCLOSE, which is consistent with the intent. If we make this change, I believe APPLICATIONCLOSE needs to be on the list as well. Now that we discuss ack-eliciting in transport, I think we'd need to change both transport and recovery and mark this design. So I think this would be a slight improvement, but I an also imagine people claiming that CONNECITON_CLOSE is already special, so there's no need for a change.
APPLICATION_CLOSE is no more. This seems like a fine change.
This seems sensible.
Discussed in Cupertino. Obvious correction.
Seems right to me. Editorial tweaks suggested.


Question: migrates away from a local address SHOULD retire all connection IDs used on that address once it no longer plans to use that address. <del> An endpoint can request that its peer retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field.  Upon receipt, the peer SHOULD retire the corresponding connection IDs and send the corresponding RETIRE_CONNECTION_ID frames in a timely manner.  Failing to do so can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route </del> <ins> An endpoint can cause its peer to retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field. Upon receipt, the peer MUST retire the corresponding connection IDs and send corresponding RETIRE_CONNECTION_ID frames.  Failing to retire the connection IDs within approximately one PTO can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route </ins> correctly. An endpoint MAY discard a connection ID for which retirement has been requested once an interval of no less than 3 PTO has elapsed since an acknowledgement is received for the NEW_CONNECTION_ID frame <del> requesting that retirement.  Subsequent incoming packets using that </del> <ins> requesting that retirement.  Until then, the endpoint SHOULD be prepared to receive packets that contain the connection ID that it has requested be retired.  Subsequent incoming packets using that </ins> connection ID could elicit a response with the corresponding stateless reset token.

NAME The text in the PR adopts 1 PTO as a suggestion, as I am not sure if there is a point in that value being the exact limit. If it needs to be, we can rephrase the text to "MUST retire the corresponding connection IDs in one PTO and send corresponding RETIRECONNECTIONID frames."
I'm a bit worried that a stateless reset from a retired CID could be used as an attack vector by simply delaying packets en-route. However, if the reset is only effective on CIDs that are no longer recognised that shouldn't be a problem.
At the moment, states, quote: Upon receipt, the peer SHOULD retire the corresponding connection IDs and send the corresponding RETIRECONNECTIONID frames in a timely manner. Failing to do so can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route correctly. As the text uses "SHOULD" rather than a "MUST", some view it as an optional requirement to switch to using a new connection ID in such a situation. Others think that it is a mandatory requirement for an endpoint to switch to a new connection ID. If we are to consider the latter behavior to be the case, I think the text should better be changed to "MUST retire the corresponding connection IDs and send the corresponding RETIRECONNECTIONID frames in a timely manner".
My personal take is that it would be nice if the processing of NEWCONNECTIONID frame and RETIRECONNECTIONID frame can be an optional feature. QUIC is already very complex, and it would be beneficial to have some features being optional, in sense that endpoints can simply discard certain frames when not implementing certain features. IIUC, at the moment, these two frames are optional for an endpoint that do not support migration. OTOH, from the robustness viewpoint of the protocol, it does make sense to change the text to MUST. We might have already crossed the river by introducing the Retire Prior To field. The third option is to add a TP that indicates if an endpoint supports retirement of connection IDs...
There was a lot of discussion when the Retire Prior To feature was added. At the time, I felt it pretty clear that it could not be optional from our server's perspective.


Question: migrates away from a local address SHOULD retire all connection IDs used on that address once it no longer plans to use that address. <del> An endpoint can request that its peer retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field.  Upon receipt, the peer SHOULD retire the corresponding connection IDs and send the corresponding RETIRE_CONNECTION_ID frames in a timely manner.  Failing to do so can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route </del> <ins> An endpoint can cause its peer to retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field. Upon receipt, the peer MUST retire the corresponding connection IDs and send corresponding RETIRE_CONNECTION_ID frames.  Failing to retire the connection IDs within approximately one PTO can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route </ins> correctly. An endpoint MAY discard a connection ID for which retirement has been requested once an interval of no less than 3 PTO has elapsed since an acknowledgement is received for the NEW_CONNECTION_ID frame <del> requesting that retirement.  Subsequent incoming packets using that </del> <ins> requesting that retirement.  Until then, the endpoint SHOULD be prepared to receive packets that contain the connection ID that it has requested be retired.  Subsequent incoming packets using that </ins> connection ID could elicit a response with the corresponding stateless reset token.

I agree the sentence with the SHOULD, if read in isolation, could be interpreted as making the feature as optional. But the sentence immediately following it makes it pretty clear that it's not option. I understand the desire to make things optional for simplicity's sake, but a primary point of this feature, when it was added, was that is was required. Making it optional now would, IMO, defeat the purpose of the feature.
My understanding is that this is optional in the sense GOAWAY is optional. At some point, the connection is likely to terminate abruptly if you don't follow the request.
That's one way to look at it. The difference here is that we're not trying to kill the connection with Retire Prior To.
There was definitely lots of discussion around the requirement level here when this was added (see ), NAME asked: There was good discussion following that ( and scroll down). My understanding of was that the endpoint being asked to retire a CID really SHOULD retire it or else the peer may stop responding to that CID. After the endpoint requesting retirement gives up on a CID and forgets about it, packets will either arrive with that CID or they will not. It has two choices, it can choose to process them if they arrive with the wrong CID, or it can drop them. The enforcement mechanism here is to stop processing the "bad" CIDs, not close the connection, especially as you take into account potentially delayed-but-valid packets. I think the current stance of "really SHOULD stop using such a CID, but the other endpoint needs to be careful about enforcing that" is the right one, if there's a wording update that would help with understanding there, then it would be great to update the wording as an editorial issue.
Whatever the answer here, the SHOULD was chosen because "timely manner" isn't defined in a testable fashion. If someone wants to argue for MUST, then we need a firmer definition of the reaction.
And to agree with NAME the squishiness here only exists up until the point that this is "do this or else". We should make it clearer that the cost of non-compliance is losing the connection. Not always, but a endpoint is entitled to cut and run if their peer doesn't comply.
NAME Thank you for the explanation and the links. They help a lot in understanding how we ended up here.


Question: migrates away from a local address SHOULD retire all connection IDs used on that address once it no longer plans to use that address. <del> An endpoint can request that its peer retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field.  Upon receipt, the peer SHOULD retire the corresponding connection IDs and send the corresponding RETIRE_CONNECTION_ID frames in a timely manner.  Failing to do so can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route </del> <ins> An endpoint can cause its peer to retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field. Upon receipt, the peer MUST retire the corresponding connection IDs and send corresponding RETIRE_CONNECTION_ID frames.  Failing to retire the connection IDs within approximately one PTO can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route </ins> correctly. An endpoint MAY discard a connection ID for which retirement has been requested once an interval of no less than 3 PTO has elapsed since an acknowledgement is received for the NEW_CONNECTION_ID frame <del> requesting that retirement.  Subsequent incoming packets using that </del> <ins> requesting that retirement.  Until then, the endpoint SHOULD be prepared to receive packets that contain the connection ID that it has requested be retired.  Subsequent incoming packets using that </ins> connection ID could elicit a response with the corresponding stateless reset token.

NAME Yeah we already state that "an endpoint MAY discard a connection ID for which retirement has been requested once an interval of no less than 3 PTO has elapsed since an acknowledgement is received for the NEWCONNECTIONID frame requesting that retirement." So I think it's testable. Considering that we have a MAY on the side that initiates the retirement, I think we can have a MUST on the receiver side (assuming that we want to).
That almost works, except that PTO isn't a shared variable. It's subjective and so endpoints might disagree on where this line is. At 3PTO, that's probably not a disagreement worth having, but you are effectively recommending instant compliance if you set the bar that low, as packet loss on any packet sent that attempts to comply might cause it to take up to 3PTO to get through.
IIRC, the base of the SHOULD was that we didn't have a specific timeout anyone felt comfortable enforcing in the absence of shared timers between peers. We've had a general principle that requirements you can't tell whether the peer violated are probably SHOULDs instead of MUSTs. As Nick says, the SHOULD is intended to refer to doing so promptly, not to doing so at all.
While I agree that we have tried to make MUST requirements testable, I am not certain if it is a good idea to avoid use of MUST when a requirement cannot be tested (or if doing so is a good idea, per the definition of the keywords in RFC 2119). At least for this particular case, isn't it a requirement for an endpoint to drop the old connection IDs? Though I could well be wrong though in how the keywords are used in practice.
I'm fine saying MUST drop in a timely manner, and being explicit about what we mean by timely manner (3 PTO from the peer's perspective). Obviously, from the peer's perspective, that is enforceable. Locally though, it's obviously not as clear cut.
We need a PR. NAME do you think that you can do this? As discussed, should be that the receiving side will retire within one PTO. The sending side can enforce at 3PTO, by dropping the connection.
Discussed in Cupertino. NAME to quickly rev the PR to incorporate NAME suggestion.


Question: migrates away from a local address SHOULD retire all connection IDs used on that address once it no longer plans to use that address. <del> An endpoint can request that its peer retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field.  Upon receipt, the peer SHOULD retire the corresponding connection IDs and send the corresponding RETIRE_CONNECTION_ID frames in a timely manner.  Failing to do so can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route </del> <ins> An endpoint can cause its peer to retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field. Upon receipt, the peer MUST retire the corresponding connection IDs and send corresponding RETIRE_CONNECTION_ID frames.  Failing to retire the connection IDs within approximately one PTO can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route </ins> correctly. An endpoint MAY discard a connection ID for which retirement has been requested once an interval of no less than 3 PTO has elapsed since an acknowledgement is received for the NEW_CONNECTION_ID frame <del> requesting that retirement.  Subsequent incoming packets using that </del> <ins> requesting that retirement.  Until then, the endpoint SHOULD be prepared to receive packets that contain the connection ID that it has requested be retired.  Subsequent incoming packets using that </ins> connection ID could elicit a response with the corresponding stateless reset token.

NAME the delayed packets are handled by this text: If you've followed the requirement to retire as indicated, then a delayed packet triggering stateless reset can't hurt you.Looks fine to me. I'm also fine with Martin's suggestions as well.The endpoint here has always been going to do whatever it does, regardless of whether we said SHOULD or MUST, so this seems fine. I do like the direction for the other endpoint to wait 3PTO, that would be nice to include.


Question: 5.1. <del> TODO - Add example with string, data, boolean, and base value </del> 5.1.1. The following shows a temperature reading taken approximately "now"

Fixes URL
This makes some of the examples very long. I preferred the presentation where all attributes of a Record are on a single line, when feasible. Especially for the "multiple data points" examples. Anyway, Michael's comment was about indentation, which I agree should be (and is now) fixed.
See email from Michael Koster "Formatting of JSON examples in SenML"


Question: 8. <del> We can provide DATAGRAM support in HTTP/2 by defining the CAPSULE frame in HTTP/2. We can provide DATAGRAM support in HTTP/1.x by defining its data stream format to a sequence of length-value capsules. TODO: Refactor this document and add definitions for HTTP/1.x and HTTP/2. 9. </del> Since this feature requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a server supports this feature.  Implementations that support this

Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.


Question: that the load balancer will redirect the next Client Initial packet to a different server in that pool. <del> 6.3. QUIC provides for multiple Server and Client Connection IDs to be used simultaneously by a given connection, which allows seamless connection migration when one of the endpoints changes IP address and/or UDP port.  Section 6.11.5 of QUIC describes how to use this facility to reduce the risk of exposing a link among these addresses to observers on the network.  However, analysis of the lifetimes of six-tuples (source and destination addresses as well as the migrated CID) may expose these links anyway. In practice, a finite set of flows will be undergoing migration within any one time window as seen from any given observation point in the network, and any migration must keep at least one endpoint address constant during the migration.  Because of this, a key insight here is that this finite set of flows represents the anonymity set for any one flow undergoing migration within it.  For endpoints with low volume, this anonymity set will be necessarily small, so there remains a significant risk of linkage exposure through timing-based analysis. The most efficient mitigation for these attacks is operational, by increasing the size of the anonymity set as seen from a passive observer in the Internet, either by using a load balancing architecture that loads more flows onto a single server-side address, by coordinating the timing of migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. </del> 7. Versioning in QUIC may change the protocol's behavior completely,

Tries to I resisted the urge to reference the QUIC-LB draft, which isn't adopted. The major substantive change is that I removed the prohibition on non-routing information in the CID. I'm happy to discuss this if people have object.
LGTM. will go ahead and land this, then fix up the lint issues.
NAME missed this during the inconsistency, will fix in working copy
(this is done)
BTW, this was meant to address
Moving URL to the ops repo.
see also -- in any case the text that is there now is not great.
NAME can you please review the existing text (orginially provided by NAME and state what else is needed? Please have also a look at issue
This is a bit OBE, but I think there might still be value in discussing how a server implementer should think about connection IDs. Fortunately, NAME has been doing a bunch of work on this in his load balancer draft. I would suggest that we leave this issue open, and either point to the LB draft or use text from it.
fixed this
Write section to provide guidance; maybe in the same section than guidance in port selection in general


Question: Ciphersuites are represented with the CipherSuite type.  HPKE public keys are opaque values in a format defined by the underlying Diffie- Hellman protocol (see the Ciphersuites section of the HPKE <del> specification for more information): 6.1.1. This ciphersuite uses the following primitives: </del> <ins> specification for more information). </ins> <del> Hash function: SHA-256 </del> <ins> The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for the signatutes in MLSPlaintext and the tree signatures.  It can be different from the signature algorithm specified in credential fielf of ClientInitKeys. </ins> <del> AEAD: AES-128-GCM </del> <ins> The ciphersuites are defined in section mls-ciphersuites. </ins> <del> When HPKE is used with this ciphersuite, it uses the following algorithms: KEM: 0x0002 = DHKEM(Curve25519) </del> <ins> 6.1.1. </ins> <del> KDF: 0x0001 = HKDF-SHA256 </del> <ins> Depending on the Diffie-Hellman group of the ciphersuite, different rules apply to private key derivation and public key verification. </ins> <del> AEAD: 0x0001 = AES-GCM-128 </del> <ins> 6.1.1.1. </ins> Given an octet string X, the private key produced by the Derive-Key- <del> Pair operation is SHA-256(X).  (Recall that any 32-octet string is a valid Curve25519 private key.)  The corresponding public key is </del> <ins> Pair operation is SHA-256(X) (Recall that any 32-octet string is a valid X25519 private key).  The corresponding public key is </ins> X25519(SHA-256(X), 9). Implementations SHOULD use the approach specified in RFC7748 to

It seems like we have a few separable issues here: Whether we require a single signature scheme for the whole group Whether signature schemes are included in the ciphersuite Whether we have an MTI ciphersuite / signature algorithm What new ciphersuites should be defined, and what algorithms should go in them Let's discuss this at the interim and maybe break this PR into a few bits
Note that specification required registries imply that there is a designated expert pool. I will add some text to create one. The text is very similar to the TLS DE pool text from with some tweaks that, hopefully, address the misunderstandings uncovered during non-standards track registry requests. Note the process is: (assuming that the IESG eventually approves this draft) When the IESG approves this draft, the responsible AD assigns some DEs (like 2-3 suggested by the WG chairs). These DEs are in charge of all registrations regardless of whether the draft comes from the WG or elsewhere as all requests go to the MLS DEs mailing list.
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 0 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :speaker: , by It received 1 comments. - - Last week, 7 pull requests were created, updated or merged. Last week, 2 pull requests were opened. :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates.


Question: Ciphersuites are represented with the CipherSuite type.  HPKE public keys are opaque values in a format defined by the underlying Diffie- Hellman protocol (see the Ciphersuites section of the HPKE <del> specification for more information): 6.1.1. This ciphersuite uses the following primitives: </del> <ins> specification for more information). </ins> <del> Hash function: SHA-256 </del> <ins> The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for the signatutes in MLSPlaintext and the tree signatures.  It can be different from the signature algorithm specified in credential fielf of ClientInitKeys. </ins> <del> AEAD: AES-128-GCM </del> <ins> The ciphersuites are defined in section mls-ciphersuites. </ins> <del> When HPKE is used with this ciphersuite, it uses the following algorithms: KEM: 0x0002 = DHKEM(Curve25519) </del> <ins> 6.1.1. </ins> <del> KDF: 0x0001 = HKDF-SHA256 </del> <ins> Depending on the Diffie-Hellman group of the ciphersuite, different rules apply to private key derivation and public key verification. </ins> <del> AEAD: 0x0001 = AES-GCM-128 </del> <ins> 6.1.1.1. </ins> Given an octet string X, the private key produced by the Derive-Key- <del> Pair operation is SHA-256(X).  (Recall that any 32-octet string is a valid Curve25519 private key.)  The corresponding public key is </del> <ins> Pair operation is SHA-256(X) (Recall that any 32-octet string is a valid X25519 private key).  The corresponding public key is </ins> X25519(SHA-256(X), 9). Implementations SHOULD use the approach specified in RFC7748 to

:smiley: You can also .
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 0 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 4 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there was 1 commit. :hammerandwrench: by - - Last week there was 1 contributor. :bustin_silhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
This seems to accurately reflect the consensus we had at the last interim, and there's nothing I can't live with otherwise. I will probably file a follow-up to convert the Derive-Key-Pair operations to use HKDF directly, as discussed, avoiding the need for intermediate values or truncation of SHA-512.


Question: 3.7. <del> JSEP supports simulcast of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section.  The current JSEP API is designed to allow applications to send simulcasted media but only to receive a single encoding.  This allows for multi-user scenarios where each sending client sends multiple encodings to a server, which then, for each receiving client, chooses the appropriate encoding to forward. </del> <ins> JSEP supports simulcast transmission of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section.  The current JSEP API is designed to allow applications to send simulcasted media but only to receive a single encoding.  This allows for multi-user scenarios where each sending client sends multiple encodings to a server, which then, for each receiving client, chooses the appropriate encoding to forward. </ins> Applications request support for simulcast by configuring multiple encodings on an RTPSender, which, upon generation of an offer or

Originally raised by Magnus: Section 3.7: JSEP supports simulcast of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section. I think this should be explcit that it is "simulcast transmission of a MediaStreamTrack".


Question: If the "path_secret" value is set in the GroupSecrets object: Identify the lowest common ancestor of the leaf node "my_leaf" <del> and of the node of the member with LeafNodeRef </del> <ins> and of the node of the member with leaf index </ins> "GroupInfo.signer".  Set the private key for this node to the private key derived from the "path_secret".

This seems to be a layer of indirection that doesn't add any value to implementation.
The Credentials section claims there is an epoch id field in key packages. I don't think that actually exists. My apologies if this is a duplicate issue.
Addressed in but may need to be pulled out depending on the fate of that PR
contains all of the Proposals that were previously sent within the same epoch. This seems unnecessary, since all members should have them anyway. The list of in the actual message should be enough for members to parse and validate a message. We should discuss if we can de-duplicate this, since the list of Proposals might be quite long.
The current definition of is as follows; Maybe this issue is obsolete?
Seems it is now obsolete indeed.
I don't have a strong opinion on this question, but this change seems sensible to me. The use of LeafNodeRef requires either (a) a linear scan through the tree, which is time-expensive in large trees, or (b) keeping an index that maps LeafNodeRef values to indices, which is storage-intensive in large trees. IIRC, the change to LeafNodeRef was made in the context of NAME work to make the tree description less tied to the array representation. In general, that is the right thing to do, and it's good that we did it. But we still have leaf indices anyway, for . Since we still have the concept, we might as well use it where it makes sense. And it certainly seems to me like and make sense, since they are internal to the protocol. In case folks are worried about the application-facing API -- MLS stacks can certainly be more intelligent, e.g., exposing or or . But they can do that regardless of this PR.


Question: based on RTP and may be the closest in terms of features to WebRTC, is not compatible with the SDP offer/answer model RFC3264. <del> In the specific case of media ingestion into a streaming service, some assumptions can be made about the server-side which simplifies the WebRTC compliance burden, as detailed in WebRTC-gateway document draft-ietf-rtcweb-gateways. </del> <ins> So, currently, there is no standard protocol designed for ingesting media into a streaming service using WebRTC and so content providers still rely heavily on protocols like RTMP for doing so.  Most of those protocols are not RTP based, requiring media protocol translation when doing egress via WebRTC.  Avoiding this media protocol translation is desirable as there is no functional parity between those protocols and WebRTC and it increases the implementation complexity at the media server side. Also, the media codecs used in those protocols tend to be limited and not negotiated, not always matching the mediac codes supported in WebRTC.  This requires to perform transcoding on the ingest node, which introduces delay, degrades media quality and increases the processing workload required on the server side.  Server side transcoding that has traditionally been done to present multiple renditions in Adaptive Bit Rate Streaming (ABR) implementations can be replaced with Simulcast RFC8853 and SVC codecs that are well supported by WebRTC clients.  In addition, WebRTC clients can adjust client-side encoding parameters based on RTCP feedback to maximize encoding quality. </ins> This document proposes a simple protocol for supporting WebRTC as media ingestion method which:

The text says: "The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node," I don't understand this sentence. If I use an "older protocol", e.g, RTMP, why do I need to care about WebRTC codecs?
That refers if you use RTMP for ingest and WebRTC for viewing.
rewriten the editorial in
The text says: "These protocols are much older than webrtc and lack by default some important security and resilience features provided by webrtc with minimal delay." I assume you refer to RTMP, which is mentioned in the previous Section. Doesn't RTMPS solve some of the security issues? But in general, if you want to put up WHIP against RTMP, I think you need a little more text. Also, as WHIP is supposed to be an "easy to implement" protocol, I think it would be fair to also list some of the functions NOT supported compared to e.g., RTMP. As I have mentioned before, there is no command for start the ingestion - it is assumed to have begun when the connection has been established. Also, there is no PAUSE/RESUME.
It is more referring to RTSP which lacks DTLS support. no command for start the ingestion - it is assumed to have begun when the connection has been established. Also, there is no PAUSE/RESUME. RTMP protocol was intended as an RPC mechanism between the flash player and server. It allowed to create custom apps both on client and server side, which supported a wide range of methods using AMF. However, current "RTMP protocol" implemented for ingesting is a reversed engineered version of the implementation done by the FMS and it lacks support for PAUSE/RESUME and the publication is started from the start of the RTMP connection (same as whip).
rewriten the editorial in


Question: lookup would provide DNS as opposed to DNSSEC responses provided by the Public Authoritative Server(s). <del> 3) Keeping the Homenet Zone and the Public Homenet Zone equal to guarantee coherence between DNS responses.  Using a unique zone is one way to guarantee uniqueness of the responses among servers and places.  Issues generated by different views are discussed in more details in sec-views. 4) Privacy and Integrity of the DNSSEC Homenet Zone are better guaranteed.  When the Zone is signed by the HNA, it makes modification of the DNS data -- for example for flow redirection -- impossible.  As a result, signing the Homenet Zone by the HNA provides better protection for end user privacy. </del> <ins> Privacy and Integrity of the DNSSEC Homenet Zone are better guaranteed.  When the Zone is signed by the HNA, it makes modification of the DNS data -- for example for flow redirection -- impossible.  As a result, signing the Homenet Zone by the HNA provides better protection for end user privacy. </ins> Reasons for signing the zone by the Outsourcing Infrastructure are:

…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.


Question: Fulfill the server's requirements for issuance <del> Finalize the application and request issuance </del> <ins> Await issuance and download the issued certificate </ins> The client's application for a certificate describes the desired certificate using a PKCS#10 Certificate Signing Request (CSR) plus a

Based on the acme mailing list discussion[0] on "proactive" vs "on-finalization" issuance it seems there is more support for the proactive approach. Speaking on behalf of Let's Encrypt and the Boulder developers we're willing to compromise and support proactive issuance as the sole issuance method in order to simplify the protocol & implementations. This PR changes the language around certificate issuance to reflect that the server MUST issue the certificate proactively once all the required challenges for an application have been fulfilled. The open issue corresponding to making this decision is removed now that there is one supported option. In an effort to close out open questions around applications this commit also removes the open issue around multiple certificates per application. If there is a demand for automating repeat issuance there should be a new thread started with a concrete proposal. 0: URL
NAME apologies! I missed your comments until today. Both are resolved in URL Thank you for the feedback.
Oh! They were fresh and I misread the dates. Not such a bad turn around after all :-)
NAME Fantastic, thanks. Merging. Hi folks, I wanted to revisit a discussion on the server proactively issuing certificates. Section 4, "Protocol Overview"[0] currently has a paragraph that reads: the the application be to the There is also an "Open Issue" remark related to proactive issuance in Section [1]. I think the specification should decide whether proactive issuance or on-finalization issuance should be used instead of allowing both with no indication to the client which will happen. It's the preference of Let's Encrypt that the specification only support on-finalization issuance. This is cheaper to implement and seems to be the path of least surprise. It also seems to better support large volume issuance when the client may want explicit control over when the certificates for multiple applications are issued. In the earlier "Re: [Acme] Preconditions" thread[2] Andrew Ayer seems to agree that there should be only one issuance method to simplify client behaviours, though he favours proactive issuance instead of on-finalization issuance. While it saves a round-trip message I'm not sure that this alone is convincing enough to choose proactive issuance as the one issuance method. What are the thoughts of other list members? Daniel/cpu [0] URL [1] URL [2] URL


Question: access control mechanisms SHOULD be used to protect it such as file system controls, physical security or hardware security modules. <del> 6.2. </del> <ins> 6.3. </ins> Delegated credentials do not provide any additional form of early revocation.  Since it is short lived, the expiry of the delegated

Based on The delegation certificate MAY have the DelegationUsage extension marked critical. This also adds a "strict" flag to the extension that, if set, requires the server to offer a DC. An alternative that was discussed is to add an optional TLS-feature extension (per RFC 7633) that would provide a "must-use-DC" feature, analogous to "must-staple-OCSP". Howver, it's possible for a certificate with such an extension to be used in a handshake without DCs if the client doesn't indicate support for DCs.


Question: implementation to communicate control data to the remote endpoint that can be used to parse Messages. <ins> Similarly, when a Message Framer generates a "Stop" event, the framer implementation has the opportunity to write some final data or clear up its local state before the "Closed" event is delivered to the Application.  The framer implementation can indicate that it has finished with this. </ins> At any time if the implementation encounters a fatal error, it can also cause the Connection to fail and provide an error. <ins> Should the framer implementation deem the candidate selected during racing unsuitable it can signal this by failing the Connection prior to marking it as ready.  If there are no other candidates available, the Connection will fail.  Otherwise, the Connection will select a different candidate and the Message Framer will generate a new "Start" event. </ins> Before an implementation marks a Message Framer as ready, it can also dynamically add a protocol or framer above it in the stack.  This allows protocols like STARTTLS, that need to add TLS conditionally,

Just some points about the new text on framers in the API draft: In 10.2 it is specified in which order multiple framers run on incoming and outgoing messages, it is however never specified what the order looks like on Start and Stop events. In 10.6, "MessageFramer.DeliverAndAdvanceReceiveCursor" appears to be missing the "Data" argument that is present in "MessageFramer.Deliver". Also in 10.6, in the second paragraph it says: When it is probably meant to say While the framer implementation is able to notify the Connection that it has finished handling a Start event (by calling MessageFramer.MakeConnectionReady), there is no such way for Stop events.
As notes for the responses to these points: If there are multiple framers, the "lowest" one (the one closest to the transport) would receive start first, and the next would get the start event when the lower one is ready. Similar for stop. Good calls on the missing data argument and the typo re application vs framer. I was thinking to use the failConnection call to complete a stop, potentially with no error?


Question: on multiple already existing media types. Applications using the application/multipart-core Content-Format <del> define the internal structure of the application/multipart-core representation. </del> <ins> define the semantics as well as the internal structure of the application/multipart-core representation according to the syntax described by the CDDL in mct-cddl. </ins> For example, one way to structure the sub-types specific to an application/multipart-core container is to always include them at the

…oundaries defined by the CDDL
We should add something like: " within the syntactical boundaries defined by the CDDL in Figure 1."


Question: Transport Properties MUST always be specified while security parameters are OPTIONAL. <del> Message Framers (see framing), if required, should be added to the </del> <ins> If Message Framers are used (see framing), they MUST be added to the </ins> Preconnection during pre-establishment. 5.1.

In the API doc sec 5 says. "Message Framers (see Section 10), if required, should be added to the Preconnection during pre-establishment." Should this be SHOULD or even MUST? If SHOULD is correct I think we need to say slightly more about when it makes sense to add a framer later.
I think it should be "can be added..."; not normative, just descriptive of fact.
Can we start with the "If' perhaps... "If messages frames are to be used, they MUST be added to the Preconnection during pre-establishment."?


Question: 3.5.5.2.2. <del> The comparison operators "==", "<", and ">" are defined first and then these are used to define "!=", "<=", and ">=". </del> <ins> The comparison operators "==" and "<" are defined first and then these are used to define "!=", "<=", ">", and ">=". </ins> When a path resulting in an empty nodelist appears on either side of a comparison:

Fixes URL
Thanks for your comments NAME and NAME I feel I should explain. The current draft defines the orderings and using the same text. For strings, the text talks about "less than" but not "greater than". So the current text implicitly assumes that for strings and , if and only if . Non-mathematicians would tend to say this is patently obvious. But this PR avoids that assumption by only defining using the same text and then defining in terms of . However, I take the point about the standalone definitions and the arbitrariness of defining one in terms of the other. So my question is: is the current draft text sufficiently precise? If not, I'll rework this PR to make it more precise. (When I started out doing that, it began to get quite wordy, so I changed tack.)
Despite the fact, that Glyn's approach is mathematically clean, I would favour the symmetric approach by defining , ,. I am quite sure, that nobody will cry "redundancy" then.
Yes. Is that a problem? comes before ...
Actually, on the symmetry point, we were comfortable defining in terms of and that was asymmetric.
In what system of mathematics are operations ordered? This is completely arbitrary. I'm not convinced this needs to change. I prefer defining both and . And for symmetry, I'd change strings to match.
Applying editorial discretion here. Merging.
The current spec defines string comparison using one of the operators , , , or in terms of when one string is less than another. That's fine for , but: for it effectively assumes is fixed (i.e. that for strings and if or ) for and it leaves quite a lot to the reader's imagination. Once we've settled on , the above should be addressed. ~We should also adopt a similar approach for ordered comparisons () of arrays if is adopted.~ (It wasn't.) (I labelled this issue as because I don't believe it will change the intended semantics in either case.)
I propose to let URL land before addressing this issue.
I personally prefer the previous version, with standalone definitions, but think this is a matter of editorial discretion.I agree with Tim. It's fine and correct to define in terms of other operators, but I feel and should both be equally defined.


Question: 3.5.5.2.2. <del> The comparison operators "==", "<", and ">" are defined first and then these are used to define "!=", "<=", and ">=". </del> <ins> The comparison operators "==" and "<" are defined first and then these are used to define "!=", "<=", ">", and ">=". </ins> When a path resulting in an empty nodelist appears on either side of a comparison:

Defining one in terms of the other means you have to make an arbitrary choice of which is directly defined and which is indirectly defined.This PR is exactly the right way to do this.


Question: widely deployed, this section discusses considerations for future versions to help with compatibility with QUIC version 1. <del> 6.1. </del> <ins> 7.1. </ins> QUIC version 1 features Retry packets, which the server can send to validate the client's IP address before parsing the client's first

Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM


Question: 4.2. <ins> This document defines multiple new capsule types that allow endpoints to exchange IP configuration information.  Both endpoints MAY send any number of these new capsules. </ins> 4.2.1. The ADDRESS_ASSIGN capsule allows an endpoint to inform its peer that

Good point, added. Note that I've also added an important note about how ROUTEADVERTISEMENT and ROUTEWITHDRAWAL coexist, please take a look NAME and NAME .
As discussed in , turning a sequence of ROUTEADVERTISEMENT and ROUTEWITHDRAWAL capsules into a functional routing table isn't as simple as initially expected. This is because two separate capsules can describe prefixes that are distinct but overlap. We should simplify the design or better explain the caveats.
I think the capsules description needs to be explicit if multiple capsules are allowed. I think there are different considerations depending on what type of capsules are used. The authors have already discussed and concluded that multiple routeadvertisement will be needed to allow to declare reachability of multiple prefix. I don''t know if multiple addressassign capsules are allowed. Allowing multiple allows multiple address ranges to be declared. However, that results that we also get the question if one need to withdraw source address prefixes..
Yes, multiple capsules of each type are allowed. It does seem useful to clarify this, and what it means to receive multiple addresses and multiple routes (which are additive). NAME can you help write this?
Agreed, multiple capsules of all currently defined capsule types are allowed. For example, multiple ADDRESS_ASSIGN are needed to support a dual-stack tunnel. I'll write a PR.


Question: Security considerations for DetNet are described in detail in I- D.ietf-detnet-security.  General security considerations are described in RFC8655.  DetNet IP data plane specific considerations <del> are summarized in I-D.ietf-detnet-ip.  This section considers exclusively security considerations which are specific to the DetNet IP over TSN sub-network scenario. </del> <ins> are summarized in RFC8939.  This section considers exclusively security considerations which are specific to the DetNet IP over TSN sub-network scenario. </ins> The sub-network between DetNet nodes needs to be subject to appropriate confidentiality.  Additionally, knowledge of what DetNet/

ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)


Question: This proposal supports the negotiation of either the use of one packet number space for all paths or the use of separate packet <del> number spaces per path.  While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly different latencies, this approach requires the use of a connection ID.  Therefore use of a single number space can be beneficial in highly constrained networks that do not benefit from exposing the connection ID in the header.  While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility.  More evaluation and </del> <ins> number spaces per path.  While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility.  More evaluation and </ins> implementation experience is needed to select one approach before final publication.  Some discussion about pros and cons can be found here: https://github.com/mirjak/draft-lmbdhk-quic-

Not sure to understand why the last part of the sentence is an issue. The use of zero-length connection IDs is problematic anyway in setups with NATs, for example.
I agree that in many deployments you want at least one CID from the client to server. Multiple packet numbers as currently defined however requires CIDs in both direction; there is separate issue to discuss that. The next sentence also further explains that there might be other deployments though, e.g. in constraint networks, that might also benefit from saving the bits of the CID. This one sentence is of course only a very brief summary of the pros and cons of the different approach and more discussion is needed in the group. So I don't expect to have this part in the draft like this when we finally publish it as RFC. Is there anything in the issue that we need to address now? Or can we close this issue?
Thanks, Mirja. That's what I expected, but I do still think more elaboration is needed for this text to be useful. I would suggest to make this modification and leave the discussion of pros/cons to be adequately documented in Section 7: OLD: This proposal supports the negotiation of either the use of one packet number space for all paths or the use of separate packet number spaces per path. While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly different latencies, this approach requires the use of a connection ID. Therefore use of a single number space can be beneficial in highly constrained networks that do not benefit from exposing the connection ID in the header. While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility. More evaluation and implementation experience is needed to select one approach before final publication. Some discussion about pros and cons can be found here: URL URL NEW: This proposal supports the negotiation of either the use of one packet number space for all paths or the use of separate packet number spaces per path. While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility. More evaluation and implementation experience is needed to select one approach before final publication.


Question: This proposal supports the negotiation of either the use of one packet number space for all paths or the use of separate packet <del> number spaces per path.  While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly different latencies, this approach requires the use of a connection ID.  Therefore use of a single number space can be beneficial in highly constrained networks that do not benefit from exposing the connection ID in the header.  While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility.  More evaluation and </del> <ins> number spaces per path.  While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility.  More evaluation and </ins> implementation experience is needed to select one approach before final publication.  Some discussion about pros and cons can be found here: https://github.com/mirjak/draft-lmbdhk-quic-

Some discussion about pros and cons can be found here: URL URL
You are suggesting to strike out the sentences that try to summarize the differences, "While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly different latencies, this approach requires the use of a connectionID. Therefore use of a single number space can be beneficial in highly constrained networks that do not benefit from exposing the connection ID in the header." I think that's a good idea. The sentences are a short summary of the arguments presented in the powerpoint, which are not limited to "highly constrained networks". For example, the Chrome browser, by default, uses NULL CID. I may be placing words in the mouth of Google developers, but I believe their goal is to reduce the overhead of the QUIC header compared to TCP/TLS. This is related to a general quest for performance, not to network constraints.


Question: first record is at position 1.  A range of records can be selected by giving the first and the last record number separated by a '-' character.  Instead of the second number, the '*' character can be <del> used to indicate the last Senml Record in the Pack.  A set of records </del> <ins> used to indicate the last SenML Record in the Pack.  A set of records </ins> can also be selected using a comma separated list of record positions or ranges. (We use the term "selecting a record" for identifying it as part of the fragment, not in the sense of isolating it from the Pack -- the record still needs to be interpreted as part of the Pack, e.g., using <del> the base values defined in record 1.) </del> <ins> the base values defined in earlier records) </ins> 9.1.

Set of small editorial tweaks and aligned fragment text with new way of positioning base values
LGTM ( other than we need to decide if we use field or attribute but we can do that as separate PR)


Question: 1.2. <del> draft-07 - Integration of semi-ephemeral DH proposal. </del> <ins> draft-08 Remove support for weak and lesser used named curves. Remove support for MD5 and SHA-224 hashes with signatures. draft-07 Integration of semi-ephemeral DH proposal. </ins> Add initial 0-RTT support

Not sure if the deprecation cutoff will be at 224 bits (~112 bit security level) or 255 bits (~128 bit security level) yet, so I've just done the former for now. This drops the old curves under 224 bits, updates the extension example bytes, and deprecates MD5.
As noted on-list, SHA1 can't be as easily dealt with here, so that'll be a topic for a separate changeset.
Here's a PR for this: Question: Are we dropping all curves <224 bits or <255 bits? (was consensus ever called on this specific number?)
There was not a specific WG consensus call on this point. I hope we don't need one and that we should keep the curves in that are used and trim the ones that aren't.
Good. In that case, I'll slash everything other than secp256r1 (prime256v1 / NIST P-256), secp384r1 (NIST P-384), secp521r1 (NIST P-521), and sect571r1 (NIST B-571). (plus, of course, new CFRG curves yet to be added) PR updated. URL URL
Based on the fact that apparently precisely zero servers actually use SHA-224 for signatures, can we drop that too while we're at it? (not an exaggeration; the scan cited in the last comment shows none)
I would drop it. spt On Jun 17, 2015, at 20:09, Dave Garrett EMAIL wrote:
OK. PR updated.
NAME This can be closed now that PR has been merged.


Question: The Rendezvous() Action causes the Preconnection to listen on the Local Endpoint for an incoming Connection from the Remote Endpoint, <del> while simultaneously trying to establish a Connection from the Local Endpoint to the Remote Endpoint.  This corresponds to a TCP simultaneous open, for example. </del> <ins> while also simultaneously trying to establish a Connection from the Local Endpoint to the Remote Endpoint. If there are multiple Local Endpoints or Remote Endpoints configured, then initiating a rendezvous action will systematically probe the reachability of those endpoints following an approach such as that used in Interactive Connectivity Establishment (ICE) RFC5245. If the endpoints are suspected to be behind a NAT, Rendezvous() can be initiated using Local and Remote Endpoints that support a method of discovering NAT bindings such as Session Traversal Utilities for NAT (STUN) RFC8489 or Traversal Using Relays around NAT (TURN) RFC5766.  In this case, the Local Endpoint will resolve to a mixture of local and server reflexive addresses.  The Resolve() action on the Preconnection can be used to discover these bindings: The Resolve() call returns a list of Preconnection Objects, that represent the concrete addresses, local and server reflexive, on which a Rendezvous() for the Preconnection will listen for incoming Connections.  These resolved Preconnections will share all other Properties with the Preconnection from which they are derived, though some Properties may be made more-specific by the resolution process. An application that uses Rendezvous() to establish a peer-to-peer connection in the presence of NATs will configure the Preconnection object with a Local Endpoint that supports NAT binding discovery.  It will then Resolve() on that endpoint, and pass the resulting list of candidate local addresses to the peer via a signalling protocol, for example as part of an ICE RFC5245 exchange within SIP RFC3261 or WebRTC RFC7478.  The peer will, via the same signalling channel, return the remote endpoint candidates.  These remote endpoint candidates are then configured on the Preconnection, allowing the Rendezvous() Action to be initiated. </ins> The Rendezvous() Action returns a Connection object.  Once Rendezvous() has been called, any changes to the Preconnection MUST

NAME 7df2d9c should address this
To we need multiple local and remote candidates. Should this be represented as either: 1) taking two lists of objects; or 2) as two objects each with multiple addresses, ports, etc. I suggest option 1, since this makes it easier to resolve a to multiple preconnections, for NAT binding discovery. Relates to but with also different types of endpoint.
I like option 1 because it contains complexity.
See this email thread: URL Copy + pasting a relevant part from an email from NAME To me at least, it wasn't clear from the text that rendezvous() would kick off ICE-style probing. It's kind of obvious (when else would it happen?), but I think it would be good for the draft to spell this out.
modulo the do-we-want-to-bind-tightly-to-ICE question... Dear all, I know way too little about rendezvous mechanisms, so I may get this completely wrong - please bear with me! It may be that I describe an issue that’s a non-issue. But, if I do understand this right, maybe that’s something which needs fixing? Ok, here it goes… Our current Rendezvous text in the API draft says the following: "The Rendezvous() Action causes the Preconnection to listen on the Local Endpoint for an incoming Connection from the Remote Endpoint, while simultaneously trying to establish a Connection from the Local Endpoint to the Remote Endpoint. This corresponds to a TCP simultaneous open, for example.” Now, if an application chooses unreliable data transmission, it may get SCTP with partial reliability, or it may (in the future) get QUIC with datagrams, or whatever… and then, the protocol may be able to do what’s needed (something similar to a simultaneous open). However, in case of UDP: Listening is quite okay, “simultaneously trying to establish a Connection” really means nothing - no packet will be sent. I believe that applications doing this over UDP will implement their own “SYN”-type signal for this - but then it’s up to the application, which, over TAPS, would need to: create a passive connection, send a Message from that same connection, i.e. using the same local address and port (I believe?)


Question: The Rendezvous() Action causes the Preconnection to listen on the Local Endpoint for an incoming Connection from the Remote Endpoint, <del> while simultaneously trying to establish a Connection from the Local Endpoint to the Remote Endpoint.  This corresponds to a TCP simultaneous open, for example. </del> <ins> while also simultaneously trying to establish a Connection from the Local Endpoint to the Remote Endpoint. If there are multiple Local Endpoints or Remote Endpoints configured, then initiating a rendezvous action will systematically probe the reachability of those endpoints following an approach such as that used in Interactive Connectivity Establishment (ICE) RFC5245. If the endpoints are suspected to be behind a NAT, Rendezvous() can be initiated using Local and Remote Endpoints that support a method of discovering NAT bindings such as Session Traversal Utilities for NAT (STUN) RFC8489 or Traversal Using Relays around NAT (TURN) RFC5766.  In this case, the Local Endpoint will resolve to a mixture of local and server reflexive addresses.  The Resolve() action on the Preconnection can be used to discover these bindings: The Resolve() call returns a list of Preconnection Objects, that represent the concrete addresses, local and server reflexive, on which a Rendezvous() for the Preconnection will listen for incoming Connections.  These resolved Preconnections will share all other Properties with the Preconnection from which they are derived, though some Properties may be made more-specific by the resolution process. An application that uses Rendezvous() to establish a peer-to-peer connection in the presence of NATs will configure the Preconnection object with a Local Endpoint that supports NAT binding discovery.  It will then Resolve() on that endpoint, and pass the resulting list of candidate local addresses to the peer via a signalling protocol, for example as part of an ICE RFC5245 exchange within SIP RFC3261 or WebRTC RFC7478.  The peer will, via the same signalling channel, return the remote endpoint candidates.  These remote endpoint candidates are then configured on the Preconnection, allowing the Rendezvous() Action to be initiated. </ins> The Rendezvous() Action returns a Connection object.  Once Rendezvous() has been called, any changes to the Preconnection MUST

- which is a matter of configuring the local endpoint, and doable if the underlying transport system can pull it off. I think there’s nothing in our API preventing an application from doing this. If all of the above is correct, the problem that I see is that an application may ask for unreliable transmission, and then have one case in which calling “Rendezvous” is the right thing to do, and another case in which it is not - so it would need to be able to distinguish between these two cases: is it a protocol with Rendezvous-capability, or do I have to do it myself. Maybe, in case of UDP, the call to Rendezvous should just fail, and our text should say that Rendezvous failing would inform the application that it would have to implement it by itself, by issuing Listen and then sending a Message to the peer. Thoughts? Am I completely off track, or is this something that needs a text fix? Cheers, Michael


Question: digital signatures.  The "extension_data" field of this extension contains a "supported_signature_algorithms" value. <del> %%% Signature Algorithm Extension enum { none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; </del> <ins> %%% Signature Algorithm Extension enum { none(0), md5_RESERVED(1), sha1(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; </ins> Each SignatureAndHashAlgorithm value lists a single hash/signature pair that the client is willing to verify.  The values are indicated


Question: If the packet is from a new encryption level, it is saved for later processing by TLS.  Once TLS moves to receiving from this <del> encryption level, saved data can be provided to TLS.  When providing data from any new encryption level to TLS, if there is data from a previous encryption level that TLS has not consumed, this MUST be treated as a connection error of type PROTOCOL_VIOLATION. </del> <ins> encryption level, saved data can be provided to TLS.  When TLS provides keys for a higher encryption level, if there is data from a previous encryption level that TLS has not consumed, this MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> Each time that TLS is provided with new data, new handshake bytes are requested from TLS.  TLS might not provide any bytes if the handshake

This check really is triggered by TLS providing new keys, not QUIC delivering data on a higher encryption level. Otherwise, in the case where no session ticket is sent, this condition would go undetected for unconsumed data at the Handshake encryption level.


Question: is running out of resources.  In these cases, MPTCP should send the MP_FASTCLOSE.  This option is illustrated in tcpm_fastclose. <del> If Host A wants to force the closure of an MPTCP connection, the MPTCP Fast Close procedure is as follows: </del> <ins> If Host A wants to force the closure of an MPTCP connection, it has two different options: </ins> <del> Host A sends an ACK containing the MP_FASTCLOSE option on one subflow, containing the key of Host B as declared in the initial connection handshake.  On all the other subflows, Host A sends a regular TCP RST to close these subflows, and tears them down. Host A now enters FASTCLOSE_WAIT state. </del> <ins> Option A (ACK) : Host A sends an ACK containing the MP_FASTCLOSE option on one subflow, containing the key of Host B as declared in the initial connection handshake.  On all the other subflows, Host A sends a regular TCP RST to close these subflows, and tears them down.  Host A now enters FASTCLOSE_WAIT state. </ins> <del> Upon receipt of an MP_FASTCLOSE, containing the valid key, Host B answers on the same subflow with a TCP RST and tears down all subflows.  Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state). </del> <ins> Option R (RST) : Host A sends a RST containing the MP_FASTCLOSE option on all subflows, containing the key of Host B as declared in the initial connection handshake.  Host A can tear the subflows and the connection down immediately. If a host receives a packet with a valid MP_FASTCLOSE option, it shall process it as follows : Upon receipt of an ACK with MP_FASTCLOSE, containing the valid key, Host B answers on the same subflow with a TCP RST and tears down all subflows.  Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state). </ins> As soon as Host A has received the TCP RST on the remaining subflow, it can close this subflow and tear down the whole

Adding Olivier's proposed text about the Fast-Close (cfr., URL) and integrated a shorter version of URL Hello, Sorry for being late with this, but the beginning of the fall semester is always too busy for me. During the summer, there was a discussion on the FASTCLOSE option that was triggered by Francois. The current text of RFC6824bis uses the FASTCLOSE option inside ACK packets, but deployment experience has shown that this results in additional complexity since the ACK must be retransmitted to ensure its reliable delivery. Here is a proposed update for section 3.5 that allows a sender to either send FASTCLOSE inside ACK or RST while a receiver must be ready to process both. Changes are marked with Fast Close Regular TCP has the means of sending a reset (RST) signal to abruptly close a connection. With MPTCP, a reguler RST only has the scope of the subflow and will only close the concerned subflow but not affect the remaining subflows. MPTCP's connection will stay alive at the data level, in order to permit break-before-make handover between subflows. It is therefore necessary to provide an MPTCP-level "reset" to allow the abrupt closure of the whole MPTCP connection, and this is the MPFASTCLOSE option. MPFASTCLOSE is used to indicate to the peer that the connection will be abruptly closed and no data will be accepted anymore. The reasons for triggering an MPFASTCLOSE are implementation specific. Regular TCP does not allow sending a RST while the connection is in a synchronized state [RFC0793]. Nevertheless, implementations allow the sending of a RST in this state, if, for example, the operating system is running out of resources. In these cases, MPTCP should send the MPFASTCLOSE. This option is illustrated in Figure 14.


Question: is running out of resources.  In these cases, MPTCP should send the MP_FASTCLOSE.  This option is illustrated in tcpm_fastclose. <del> If Host A wants to force the closure of an MPTCP connection, the MPTCP Fast Close procedure is as follows: </del> <ins> If Host A wants to force the closure of an MPTCP connection, it has two different options: </ins> <del> Host A sends an ACK containing the MP_FASTCLOSE option on one subflow, containing the key of Host B as declared in the initial connection handshake.  On all the other subflows, Host A sends a regular TCP RST to close these subflows, and tears them down. Host A now enters FASTCLOSE_WAIT state. </del> <ins> Option A (ACK) : Host A sends an ACK containing the MP_FASTCLOSE option on one subflow, containing the key of Host B as declared in the initial connection handshake.  On all the other subflows, Host A sends a regular TCP RST to close these subflows, and tears them down.  Host A now enters FASTCLOSE_WAIT state. </ins> <del> Upon receipt of an MP_FASTCLOSE, containing the valid key, Host B answers on the same subflow with a TCP RST and tears down all subflows.  Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state). </del> <ins> Option R (RST) : Host A sends a RST containing the MP_FASTCLOSE option on all subflows, containing the key of Host B as declared in the initial connection handshake.  Host A can tear the subflows and the connection down immediately. If a host receives a packet with a valid MP_FASTCLOSE option, it shall process it as follows : Upon receipt of an ACK with MP_FASTCLOSE, containing the valid key, Host B answers on the same subflow with a TCP RST and tears down all subflows.  Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state). </ins> As soon as Host A has received the TCP RST on the remaining subflow, it can close this subflow and tear down the whole

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+-----------------------+ +---------------+---------------+-------+-----------------------+ +---------------------------------------------------------------+ Figure 14: Fast Close (MPFASTCLOSE) Option If Host A wants to force the closure of an MPTCP connection, it has two different options : Option A (ACK) : Host A sends an ACK containing the MPFASTCLOSE option on one subflow, containing the key of Host B as declared in the initial connection handshake. On all the other subflows, Host A sends a regular TCP RST to close these subflows, and tears them down. Host A now enters FASTCLOSEWAIT state. Option R (RST) : Host A sends a RST containing the MPFASTCLOSE option on all subflows, containing the key of Host B as declared in the initial connection handshake. Host A can tear the subflows and the connection down immediately. If a host receives a packet with a valid MPFASTCLOSE option, it shall process it as follows : o Upon receipt of an ACK with MPFASTCLOSE, containing the valid key, Host B answers on the same subflow with a TCP RST and tears down all subflows. Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state). o As soon as Host A has received the TCP RST on the remaining subflow, it can close this subflow and tear down the whole connection (transition from FASTCLOSEWAIT to CLOSED states). If Host A receives an MPFASTCLOSE instead of a TCP RST, both hosts attempted fast closure simultaneously. Host A should reply with a TCP RST and tear down the connection. o If Host A does not receive a TCP RST in reply to its MPFASTCLOSE after one retransmission timeout (RTO) (the RTO of the subflow where the MPTCPRST has been sent), it SHOULD retransmit the MPFASTCLOSE.