From an interop discussion with NAME and NAME HTTP/1.1 the presence of a Host header: If no Host header is present, the section on describes how you determine what host is being asked for, ending with "guess" if it's an HTTP/1.0 request. HTTP/2 says that you generate an pseudo-header if sending direct-to-H2 and carry through the Host header if you're relaying HTTP/1.1. There is no discussion about what to do with an HTTP/1.0 (or 0.9) request being relayed over HTTP/2, which wouldn't have a Host header; you're neither required to generate or send one, even an empty one, nor are you given guidance about how to figure it out. HTTP/3 carries forward the H2 language (currently by reference, and explicitly after ). Do we want to have some guidance here? Or does this issue instead belong in URL to move some of the existing guidance to be HTTP version-independent? (NAME
NAME Thank you for looking into the problem. Regarding if (or how) we should handle the issue, I think my weak preference goes to having one rule that applies to both HTTP/2 and HTTP/3. That would be less surprising to the users, and would also be helpful to implementations. It could well be the case for an HTTP server to have a common logic of handing pseudo headers (or lack of) between HTTP/2 and HTTP/3.
Host is an HTTP/1.x header field (it was just late to the party), so HTTP/1.0 includes it as an extension. And that requirement is specific to HTTP/1.1, so would theoretically not apply to HTTP/1.2 (and that was intended): it was a short term requirement imposed by the IESG because they wanted to require deployment and didn't understand that it was already deployed. In general, I don't understand why ":authority" exists (as opposed to always using ":host"), but I think the HTTP requirement is simply that the identifying data must be present somewhere in the request.
":authority" exists for the purpose of always transporting the equivalent of the , with ":scheme" and ":path" transporting the rest. It's mostly a consistency thing, I think. If you have a "Host" header instead, that's acceptable, too.


So should we say that the target authority MUST be present in either "Host" or ":authority", or do we leave it alone?
Well, assuming we still allow requests for URIs that do not have an authority component (e.g, a URN or similar), I think it is better to just leave it alone. OTOH, folks are still going to ask what needs to be sent when the request target doesn't have an authority component, so that ought to be defined somewhere here more sensibly than it was for 1.1.
Discussed in ZRH. Proposed resolution is that if a URI scheme has a mandatory component, it better have one of those two things, preferably a :authority. Alert httpbis.
Doesn't this beg the question "what if the request is for a URI that does not have a mandatory authority component?" All of the other cases are described. I would add something like: Thanks!


I strongly think that all 10 EDHOC-KDF should be in the same table The text about maclengthx need to use the defined term hash_length
I made one commit for review.


PTO packets always have to be ACK-eliciting, not just during the handshake, per existing text: "When a PTO timer expires, a sender MUST send at least one ack-eliciting packet in the packet number space as a probe,..." Also removed an "unless" clause, because if there's nothing to send, you don't arm the PTO timer.


Previously the text was specific to policy for Evidence, but the same applies to policy for appraising Attestation Results, so generalizing the text. This also removes a redundant sentence where older text and newly merged text from this morning said the same thing. And the diffs look larger than they really are, since some text was just moved around to be in a different order. Signed-off-by: Dave Thaler


URL This definition of a handshake message is being defined in terms of a Proposal or Commit object, neither of which are defined in this session. Furthermore, PublicMessage or PrivateMessage aren’t defined either as this point in the text. To improve clarity, consider defining these key terms. The use of "respectively" in the text is suggesting that PrivateMessages don’t have integrity protection which is not accurate. (see the Cryptographic Dependencies section of the HPKE specification for more information). Is this Section 4 of RFC9180?  If so, why not say that? What would be the circumstance where the application_id extension would be treated with equal standing as something from the AS?  Why can’t this be a "MUST"? Unsaid is what to do if the proposal list is not valid.  Please clarify. Is this normative behavior required, or could it be left up to application?  The mixing of updates/removes on the same node and the SHOULD guidance already means that this "recovery from an invalid node" may not be consistent across clients/DS-es. Same observation on recovering from ReInit with any other proposals. Is there any additional retry mechanism?  Let’s say the sender of the proposal doesn’t see it reflect in the epoch after it sent proposal.  And then not in the next epoch.  Does it try resending indefinitely? This setup seems a little simplistic. If the application data is encrypted to begin with, how does the adversary know the question being posed by Alice?


This adds an explicit Listener object to the API ( to clarify behaviour of multi-streaming protocols ( clarify behaviour and enable re-use of Preconnections (
We talk about listen objects in architecture and implementation, but not in the API. Changes needed: Let return a Listener Move the the Listener Allow Preconnection to be used multiple times.
This issue popped up while discussing and seem to be a wired QUIC multi-streaming issue, possible affecting SCTP too): When a multi-streaming protocol like QUIC allows both ends to open new streams (e.g. by cloning the QUIC connection representing the stream), the both side needs a way to get a ConnectionReceived event for a new stream. That might result in the following weird pattern: I think this needs to be documented somehow and we may need to add a Selection Property do turn off this behaviour.
Calling is an active open. Once the connection is open, the peer can open new streams, but those would surely be events on the not on the .
NAME I am not sure with this one: assuming you have a bunch of ? The first one? What happens if I close the first one?
That's a good point, and I'm not sure I know the answer, but I don't think the should fire the events. A is a potential connection, yet to be instantiated, but these connections come from an already active connection. I've never been entirely comfortable with cloning a connection as the multi-streaming abstraction. This is perhaps the first scenario where it struggles though.
I do not understand the pattern in the example. You do not get a ConnectionReceived after an active open, you need a Listen?
NAME Your assumption is true for TCP, but not for multi-streaming transports like QUIC. With QUIC, you can indeed get additional TAPS connections (QUIC streams) based on an existing, initiated connections. The question is how to handle this. NAME A possible way out would be making itself is returned by an event then.
NAME the TAPS interface is the same weather you have TCP or QUIC underneath. For TAPS an active open generates a READY event not a ConnectionReceived? I do not think your example is a valid TAPS sequence.
NAME the Ready event is not shown in the example (it would be within the first ). The problem I raised is how to model the addition of streams to a multi-streaming connection.


In case of QUIC, additional streams can be initiated by the server/listening side of the QUIC connection. If we model QUIC streams as TAPS connections, this results in events at the client (and server) side for each new QUIC stream.
NAME agree we could add , although it's a significant shift in the model. If we did that, we might also want to revisit as the way of creating a new stream on a connection, in favour of a method on . NAME did you implement this with QUIC? How does your implementation work?
I also see a problem with the communication pattern here. To me, modelling a stream as a TAPS connection means that for every new connection that a peer creates (be it a stream of an existing connection or not), I'll have to listen. So: if I expect 5 incoming connections, which may e.g. be 1 connection with 1 stream and 4 later-added streams below the API, I'll have to listen 5 times. What this also means is that the grouping notion should be a readable property - I believe that we currently only describe it as something that's actively created via clone(). Regarding code, no idea how NAME has done this, but I believe that the NEAT implementation is like I describe here. For more details on this specific aspect, see: URL
NAME We create a Listener from a Connection to handle inbound streams associated with the same parent transport connection. NAME Currently, our Listener object doesn't require calling Listen() for each new connection—you can get the event invoked many times, so it doesn't require knowing how many streams may be opened by the peer. In order to get back pressure, we're talking about having a window for how many new inbound connections will be allowed at a time.
Ok, that also sounds perfectly reasonable. Actually it seems that this (receiving multiple ConnectionReceived events on one Preconnection) is already supported by our current text, sorry for missing this! So... what is the problem we're discussing here - what do we need to change in the text? I think we need only the following: do we have a use case for one Listener getting multiple Connections without having these Connections grouped? (I guess not? Grouping is not a promise of multi-streaming.)


If so, we need the ability to query whether connections are grouped (currently grouping is only created actively via "clone"). Otherwise, we can just statically say that all Connections that are created from the same Preconnections are grouped. some kind of ConnectionReceived event for the Rendezvous case, with text saying that all Connections created off the same PreConnection are grouped. (right?) a way to provide back pressure. Here, we already have PreConnection.Stop(). In the interest of keeping things simple, do we think that intelligently switching between a listening and a non-listening mode would be enough? If so, maybe we should have a call similar to Stop which stops listening, but does not dispose of the PreConnection, such that Listen could be called again. Maybe have an "End" call which stops and disposes, and let Stop only stop listening (because "Stop", to me, indicates only stopping but nothing else).
NAME This solution sounds very reasonable – I guess we should do it the same way for TAPS and add that as Text to the API NAME Some comments: It depends – if writing a server, you might want all streams of a multi-streaming connection grouped, but not all multi-streaming connections received through the same listener. So the behaviour wether to group should be a property of the Listener. I would not group connections received through the same Rendezvous (analogous to server-style listener). We might want to add a property to the listener
NAME I agree, but: just because groups may encompass more than the Connections from one Listener doesn't mean that it would be bad to always group the Connections from one Listener (i.e., group them among themselves, but maybe group them with others too). Besides, I think that wouldn't be the listener deciding anyway. Just to understand this, are you saying "no, see my argument for case 1" ? Then we're just discussing case 1, my answer is above. Otherwise I'd say: why not? yes ... but what do you mean with ? We have , just the semantics are not what I suggested. Regarding , I think that's a good idea - my own proposal was me overdoing "keep it simple, let's not add features". Nobody needs to use this unless they want to.
NAME I guess the answer really depends on what a connection group is for you.


I always saw connection groups as an abstraction for multi-streaming connections (or their emulation) – therefore I see no use for grouping connections from multiple listeners. My opinion is auto-grouping for multi-streaming is fine, otherwise it is not. really falls out of 1 I want your semantics, but call it
NAME Me too. I can imagine other things ( this paper of ours comes to mind: URL ), but generally I agree and don't think we should complicate the API for this. But I'm getting confused: you wrote "you might want all streams of a multi-streaming connection grouped, but not all multi-streaming connections received through the same listener". That sounded to me like you want to support multiple streams, but from several listeners?! ACK Agreed!
NAME let me elaborate on this… You might want all streams of a multi-streaming connection grouped, e.g., all streams within a QUIC connection You might not want all multi-streaming connections (e.g., QUIC connections) received through the same Listener object grouped You definitely do not want all all streams of all QUIC connection received through one listener grouped (except if you have hierarchical groups that allows you to sort that out the cases above)
I agree with all this. Anyway I think it's a moot point: whether they're grouped or not is not up to the listener to decide? So grouping needs to be something that can be queried.
Ok – fair enough – but I still think the Listener is the right place to configure whether connections that come out of it should be grouped by default or not.
Not unless we have a concrete idea on what to do with this information inside the transport system. => I think no text update is needed as a result of this issue and lean towards closing it...
I don't think we really need a text update for the grouping, but for the original question. To address the handling of incoming streams in multi-streaming connections, I would like to have the solution NAME outlined reflected in the API.
One question on this, for NAME the description of your Listener object being able to accept multiple events, is that how it works in general or was that specif for a multi-streaming scenario? As specified I am not sure that our Listen action does not allow multiple ConnectionReceived events? The text says
NAME The listener object for all cases (both multi streaming and receiving brand-new transport connections) allows multiple events.


I think the existing text is a bit ambiguous, but it seems that "listening continues" implies that the event can certainly fire again.
Revisit after is done
Regarding this text: This seems to imply that the Preconnection object, which may be full of many carefully tuned settings that could be useful for another Connection, is no longer usable. While I understand that the specific Preconnection cannot change for a Connection, this is inconvenient to the application. I see two good options to solve this: Make a deep copy of the Preconnection upon Initiate(), and say that a Preconnection may be used or changed but changes can no longer influence the Connection (this is what Network.framework currently does) Allow a URL() method to let the applications do the deep copy themselves when and if they want to re-use.
+1 to reusing the preconnection. Do you even need a deep copy. The connection is a new object that should be independent of the preconnection anyway, no? Another thought: Are there actually ways to get different connections out of the preconenction. E.g. you do racing and end up with two open connections and (suddenly) want to use both...?
I'd like to see this as well. To me it makes most sense to allow calling Initiate() on the same Preconnection multiple times to get multiple Connections, but not allow to change this Preconnection anymore after the first Initiate. This way it would be similar to Listen() and Rendezvous(), where we have a Preconnection that yields multiple Connections, and that cannot be changed anymore after Listen() or Rendezvous(). So here we already have a binding between the Preconnection and the Connections that come out of it. If the application wants to change the Preconnection before re-using it, I'd be in favor of letting it explicitly clone the Preconnection - not sure if we actually want to call it clone() though, because we already have Connection.Clone(), which creates a Connection Group, a completely different thing.
Why do you think it should not be allowed that a preconnection can be changed after the first initiate? If you don't change it you should get the same kind of connection, if you change it you might get something different. Your choice!
I wanted the API contract to be similar for different forms of Connection establishment. But I may be overthinking this.


First, I like the idea of reusing Preconnections. I am not sure whether we should define now whether they should be changeable after the first initiation. There might be kinds of Preconnections where this is a good idea, there might be others where it is not. I anticipate one can realize connection pools as a sub-class of Preconnection. In this case, in such cases, it should not be possible to change a Preconnection.
So the difference is if you think you morph a preconnection into a connection, or if the preconnection create the connection. i think the first think does not make sense because their are two completely different things; they have not actions or events in common.
NAME The morphing one has its beauty for modeling TCP fastopen / 0-RTT data.
Whether it makes sense to re-use a perhaps depends on how fully specified it is? Reusing a completely specified , that will just re-open an identical 5-tuple as an existing might not make sense. Reusing a partially specified , e.g., with the source port left as a wildcard to new connections can open without conflicts, seems reasonable.
NAME right, using the exact same set of fully-specified properties isn't going to work. But having a partially specified one and copying it, or modifying one that was used (by switching out the Remote, etc) would be useful.
This might work better the other way -- on , the Preconnection corresponding to the initiated/initiating connection gets deep-copied into the new connection, leaving the existing Preconnection in the state that it was. That deep copy, inside the connection, cannot be reused, but the existing one could be. (This probably only works for connections on which you . turns the preconnection into a listener from which multiple , each of which will have their own deep copy of the listener, will spawn. might be even weirder, but there's a potentially bigger win to allowing reuse, but I don't quite have my head around how it would work)
So i think there is actually not that much too deep copy because a preconception is not a super class of a connection. At the moment when you call initiate or rendezvous the preconception should create a connection and store all information regarding this connection in the connection object which is later returned.


The only thing that needs "copying" is the properties but you need to create a new object anyway because preconnection properties have preferences and connection properties not but have to be marked as mutable or unmutable. These two things are also not the same. So the only that that's left to copy maybe are the endpoints. Not sure if the preconnection and connection both have a copy of the endpoints or if an endpoint only exists once and both have a reference (which means if the endpoint gets somehow updated that's relevant for both) or maybe even the connection does not need a reference to the endpoint anymore...?
NAME right – but I don't know a way of specifying "a is consumed if fully specified, else may be reusedin any current programming language. Maybe tracking lifetimes so closely doesn't matter though, and we can just write this in the draft.
I have no problem with an Interface where some Preconnections can be reused and others can not. That makes a pretty nice case for -- preconnection reuses itself for multiple incoming connections. For ` I see this API-wise as some kind of listen called at both sides.
Side meeting says we can reuse the initiate call. Implementation should specify that a deep copy is made on Initiate() or Listen()
Will be trivial to fix after is done
Sorry to reopen an old issue, but when reading the current API draft, I noticed that it still says that reusing the Preconnection is possible for Listeners, but not possible for Initiate() and Rendezvous(). For example, see Section 6.1: "The Initiate() Action consumes the Preconnection […]" From what I read in this issue, I think Preconnections should be allowed to be reused for Initiate() and Rendezvous() as well (possibly with a note on deep-copy).
This looks just right to me, thanks a lot for doing this! In particular having read again, I believe that NAME should definitely have the last word on this one. So I'll go with whatever NAME says.


We need to discuss what information will be used to identify the UE from the perspective of the various components in the system. This updates the draft to discuss this concept, including desired properties of the identifier and some examples. This aims to address issue 5 (URL)


This adds SO_reuse commentry on the multicast UDP service. It seeks to
The implementation document should explain IGMP joining and SO_REUSEADDR for multicast
Text blob for thought or incorporation: In some uses, it is required to open multiple connections for the same address(es). This is used for some multicast applications. For example, one connection might be opened to listen to a multicast group, and later a separate one to send to the same group; two applications might independently listen to the same address(es) to send signals to and/or receive signals from a common multicast control bus. In these cases, the interface needs to explicitly enable re-use of the same set of addresses (equivalent to setting SO_REUSEADDR in the socket API).


I didn't notice this change in NAME PR , but I think the older text is more correct. I added a bit more detail about why it cannot be treated as an acknowledgement. URL
NAME I updated the text to reflect both the lack of processing and packet number.


The spec describes an optional trial decryption mode, but most of the text contradicts it. This PR fixes the text up and tries to unify their processing models. In doing so, it flips the error handling from decrypterror to fallback to be consistent. This, combined with the ClientHelloOuterAAD change, plugs an active sticking out attack for free. It also makes easier because GREASE configid collisions with real configids are now harmless. Along the way, NAME and NAME observed that we're not authenticating the ECHConfig at all. (It used to be authenticated by way of the configid, which was a digest.) Instead, just pass the ECHConfig into the info field of the HPKE context. They also noticed the server rule about PSKs on ClientHelloOuter didn't work with GREASE. Instead, we can simply remove it.
This matches the acceptance signal length, and we've already accepted that probability of collision.


This provides two band-aids to URL, and may also close it far enough that RD can progress without the underlying topic being solved in full.
This is a tracking issue to cover the topics of URL -- see there for discussion, the issue is primarily kept for cross-linking PRs.
Since this is covered well enough that it need not stop RD. Further exploration should happen in ACE and CoRE. Hello CoRE, one of the outstanding issues in RD is server authorization with respect to operations on particular paths. This continues an ACE thread[1] I regrettably missed to follow up on, but simplifies the examples based on the recent interims. While originally phrased as the attacker tricking the server into using the client's good credentials for something the client did not intend, here they are phrased now in terms of server authorization as relevant for RD discovery and RD security policies. For two examples, a client needs to trust a server to provide a service, but has received misleading hints that cause disagreement between the client and the server about the performed operation. Example 1 An RD with a "links are confidential" policy also operates a bulletin board at . During the unprotected discovery phase, the endpoint is fed a link . The client connects to URL, verifies that its server credentials are good for an RD that will reveal links posted to it only to authorized lookup clients. It then posts all its links to /bb, where anyone who knows to use a bulletin board can read them. Example 2 A time server also exposes its current core temperature as . A malicious RD operator modifies the time server's registration to read . A starting device in the network asks the RD for any rt=unixtime, verifies that URL is indeed authorized to give the right time, and wakes up on the morning of January 1st, 1970. Problem summary The client has an abstract intention with an operation, which it checks against the server's authorization. Then it forms that intention, with additional unverified knowledge about the server, into a request, which it protects. The server then reconstructs that intention with its authoritative knowledge of itself, and uses any client provided credentials to act on it. If the client's knowledge about the server is erroneous, the intentions are misaligned.


Neither is the intention protected, nor does the client point out the claims it wants to hold the server to in its request (or, in the original examples from the ACE thread, express the precise claims about itself it intends the server to assess). Solution approaches In the ACE thread back then, Jim said that he'd expect the client to use different keys (originally in talking to the AS, and thus different keys in talking to the RS). Doing that to the end would probably result in the devices having to handle a lot more keys, something like one for any operation that could be mixed up with any other? Michael in the last interim mentioned that in OAuth it's common to only run one service on one host for the very same reason. Kind of boils down to the same thing, as virtual-hosting these services would create multiple keys. My approach in the -25 RD Section 7.2 is to (losely, there; would need stronger and more precise wording) say that any information that any information using which intention is encoded in the request in a lossy way is to be rechecked from the origin server. That'd be more or less straightforward for example 1, but incur an additional costly recheck with the origin server about many things that could be learned efficiently from the RD. Does any of that solve the issues? Can we do any better? How do we put that into RD to satisfy the small comment about Section that opens this can of worms? Is there anything quotable on OAuth's best practices on multiple services on the same host? Best regards Christian [1]: URL To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom


There are two cases where the term seems to be used with importance. I suspect that the Internet isn't actually that important in the context / scope of this protocol document, especially since the architecture document doesn't mention it.
Yep, good catch. It's not.
Is there a more polite way to phrase this disclaimer?
This follows RFC 2119 (URL) and RFC 8174 linked from terminology where these are reserved phrases with specific meaning in IETF specifications and documents. Though technically these should probably be "SHOULD NOT" and "SHALL NOT" to be in line with the RFC terms.
What requirements are being defined in the quoted text though? Is it simply a statement of fact like "this document doesn't cover architectural stuff" or is it "implementations of the issuance protocol SHOULD account for considerations related to operations and privacy described in the architecture document"?
NAME this is just a statement of fact -- we don't need to shout it =)


URL is probably not your intent, but that is what you get with this phrasing. I think that the point is that the values are not predictable to entities other than the one generating it. This appears in several places in the document.
Well URL uses "indistinguishable from random" :-) But OK, I'll seek a new formulation.


Thanks to NAME for spotting this.
NAME I presume you are ok with this change, so I'm going to merge it. Any concern, let me know and we can adjust the result.
Yes. Just didn't have chance to check this in context, but if I remember this properly, this change is good (and necessary).


Thanks to Lucas for finding the study. Note that I found at least one middlebox with a default timeout of 30s; that was not a home gateway included in this study.
says that "experience shows" you should send packets every 15-30 seconds, RFC4787 notwithstanding. Ideally, we would have a source that we could reference for this "experience."
Maybe see URL
I'm going to say that while the 15s floor is a good requirement, I don't want to cite RFC 8085 for this gem, which I think is straight-up misinformation: "NATs require a state timeout of 2 minutes or longer [RFC4787]." We do cite RFC 8085 elsewhere and that's fine, but the fact here is that the IETF has requested that NATs provide a state timeout of 2 minutes. That does not mean that they do.
I have seen anecdata as well that showing 30 seconds is an important threshold. I think the ref we now have is good.


by adding a one byte IMMEDIATE_ACK frame.
editorial nit: my preference would be for frame diagrams to use the notation in QUIC transport. I see that ACK_FREQUENCY is defined using ASCII art, so perhaps you want to consider a separate follow up PR to switch styles after this lands.
Thanks Lucas, I filed to update them.
They currently use ascii art. Will write this up once is merged.
sgtm, thanks!
When sending a PTO packet, a sender wants to induce an immediate ACK. The only trick I know to induce such an ACK is intentionally skip the packet number. However, the problem of that approach is that it relies on the receiver not ignoring reorders. When an ACKFREQUENCY frame previously sent had set the bit, then it become impossible for a sender to induce an immediate ACK when sending a PTO packet. At the moment, the only solution is to bundle an ACK_FREQUENCY packet in each PTO packet, but that seems like a bit of unnecessary overhead to me. Should we have a dedicated frame for inducing immediate ACKs instead?
That's an option. Another option is to revisit the max_reordering idea discussed in . If the max reordering was 5, then you could skip 5 PNs. I do feel like it'd be nice to allow specifying an int for max reordering, since that matches up with adaptive packet threshold loss detection, but as I expressed in , I think getting the details right are deceptively difficult, so I'm torn.
This does seem like a real problem. I like the idea of a single "ELICIT_ACK" type frame. With one byte a sender could effectively mark its PTOs ensuring they get an ACK without relying on the trick. An explicit frame is also easier to implement for the sender than the packet number skipping.
There's quite a bit of discussion on this on the tcpm mailing list at the moment, ie: URL I'm increasingly thinking it's worth using an unused protected bit in the header for this. It'd end up competing with the 2-bit packet loss measurements, but given those are experimental and may never be widely deployed, I think it might be worth it. For example, I believe this could allow an implementation to not include maxackdelay in PTO if it set the "ACK-pull"(or whatever it's called) bit on the final packet.


That already seems possible if more than the threshold number of ack-eliciting packets are outstanding.
I've thought more about this, and I think most of the time a 1-byte frame would be acceptable, but it definitely adds some implementation complexity, so I'd be curious which design others prefer? If we can decide, then I'll be happy to write a PR(or NAME can). Besides PTO, a use case would be making the last packet before becoming app-limited elicit an immediate ACK. This could allow skipping maxackdelay for all PTOs(see ), though always doing it could be a bit much in some cases. For example, browsers commonly send a series of requests, but to the transport it seems app-limited between them, because it doesn't know the browser has another request to send. It might be useful for 'chirping' as well, but I've never tried that, so it's mostly speculation.
We don't currently have any intention of deploying them either, and I think that's unlikely to change. I haven't seen a lot of good evidence that they are terribly helpful, and content providers don't seem to have a good incentive for implementing it. For us at least, the difference in complexity for a frame versus a bit in the header is negligible. A frame is actually be slightly easier to implement and losing a byte here and there isn't so bad.
I strongly prefer using the header bit. Although it will be a bit more work to implement, the fact that I won't end up with a 1-byte STREAM frame that I have to split off at the end of the packet will be worth the effort.
Is testimony of network operators not taken as evidence? I remember a line of people, from different companies -- BT, ATT, and so on, at IETF 101 practically begging for some information in QUIC packets to be exposed for monitoring and troubleshooting.
I do not see anyone propose a 1-byte STREAM frame. I believe what is meant is a new frame type. If anything, using a new frame type to elicit an ACK is easier than using a header bit, as it involves fewer parts of the code to change.
Nobody is proposing a 1-byte STREAM frame (you can't just make up stream data anyway). The problem is that a new frame would consume bytes (or probably one byte) in the packet payload.


Given that you set this signal on a PTO, and PTOs are often retransmissions of packets, this would require you to repackage (and, most likely, cut off a single byte from a STREAM frame). Using a header bit would solve that problem.
NAME and I discussed this and there are number of ways to fix this, but given this issue of not being able to elicit an immediate ACK by skipping packet numbers is introduced by the draft, we feel it's important it be fixed in some way. One more option is new STREAM frame codepoints that elicit an immediate ACK.
I'm ready to write a PR, but I'd appreciate thoughts on whether the existing PING frame should be repurposed or we should add a new frame(ACK, PONG, etc). I lean towards a new frame, since there are enough code-points and I believe there are use cases for the existing PING frame that does not elicit an immediate ACK.
+1. While I would not be opposed to repurposing the existing PING frame, I do not see the necessity of doing that. Let's simply consume one code point of the remaining 33.
Thanks, now for bikeshedding time. Some possible names: ACKME ACKPULL (from TCP) FAST_ACK PONG
Putting on my bikeshedding hat: I don't think we should prefix the frame name with ACK since that almost makes it looks like yet another variant of the ACK frame. The "pull" TCP terminology is fine (e.g. PULLACK) but we could also be more explicit with something like SOLICIT_ACK.
SCTP has something similar and calls it SACK-IMMEDIATELY (RFC 7053).
Thanks, I'd be happy with ACKIMMEDIATELY or IMMEDIATEACK
For those two options I'd prefer IMMEDIATE_ACK for the same reasoning as above -- so it appears less like an ACK variant.
IMMEDIATEACK sounds good to me. Alternatively, I'd be also fine with something like ACKNOW.
IMMEDIATE_ACK it is, PR coming.


RFC8299 and RFC8466 use "inbound-bandwidth" and "outbound-bandwidth" from the point of view of the customer site. L3NM also uses this terminology from the point of view of the customer's site. L2NM flips the terminology, for example "inbound" is from PE's perspective. To avoid confusion, it would better in both L3NM and L2NM to use explicit terminology so that the direction is obvious, e.g. "PE-to-CE-bandwidth" "CE-to-PE-bandwidth" In the description field, it would be good to say which field in RFC8299/RFC8466 this corresponds to.
practically it is ingress-Policer and egress-Shaper, because the BW is controlled only from the PE side. in addition there is policer and shaper per CoS/Queue which should be addressed.
I guess you meant "input-bandwidth" and "output-bandwidth". We do have the following for the L3NM: 'inbound-bandwidth': Indicates, in bits per second (bps), the inbound bandwidth of the connection (i.e., download bandwidth from the service provider to the site). 'outbound-bandwidth': Indicates, in bps, the outbound bandwidth of the connection (i.e., upload bandwidth from the site to the service provider). >L2NM flips the terminology, for example "inbound" is from PE's perspective. 'svc-inbound-bandwidth' indicates the inbound bandwidth of the connection (i.e., download bandwidth from the service provider to the site). 'svc-outbound-bandwidth' indicates the outbound bandwidth of the connection (i.e., upload bandwidth from the site to the service provider). Please note that we do already have the following in the common I-D: "Indicates support for the inbound bandwidth in a VPN. That is, support for specifying the download bandwidth from the service provider network to the VPN site. Note that the L3SM uses 'input' to identify the same feature. That terminology should be deprecated in favor of the one defined in this module."; Which was echoed in the L3NM, e.g., "Note that the L3SM uses 'input- -bandwidth' to refer to the same concept.";
Hi Med In URL it says as follows, maybe it is a typo?


container svc-outbound-bandwidth { if-feature "vpn-common:outbound-bw"; description "From the PE perspective, the service outbound bandwidth of the connection."; But I would urge you to change the terminology to "PE-to-CE-bandwidth" /"CE-to-PE-bandwidth" to make it super-explicit, the current terminology has been causing endless confusion to implementers (I realise it's inherited from the service models, but changing the terminology in LXNM would cure the problem well)
This is a typo. It needs to be fixed. Will move this one to the list.
Julian, please check the PR at 7e5286a
Med, this is great, thanks! Can it be changed similarly in L3NM as well? Julian


Thanks both, I'll have a look today.
Looks good ! Thanks Richard!
The architecture document mentions PSKs in several places, but does not discuss the security of them. Nor does it discuss the security of External Proposals and External Commits. Notably, the third paragraph of 5.1 Membership Changes says "…the set of devices controlled by the user can only be altered by an authorized member of the group." The set of devices could be altered via an External Commit by a non-member. At the end of 5.2 Parallel Groups there is a vague mention of "using the PSK mechanism to link healing properties among parallel groups.", but no discussion of the security. Likewise Section 5.5 Recovery After State Loss talks about PSKs as the solution to a problem but the risks are not discussed. External Proposals and External Commits should be discussed in section 5.4 Access Control.
NAME I fixed the specific problems you note in


I got a little tripped up on this point! Maybe you have a better way to explain it.
Thanks, NAME


NAME said:
This particular choice has not a lot to do with QUIC and would therefore bring in a lot of non-sequitur references, but a single sentence won't hurt. It has to be repeated, which is gross, but I can live with that.


URL Francesca Palombini has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Thank you for the work on this document. I only have minor comments and nits below. Francesca sending messages to the client. A zero-length CID value indicates that the client is prepared to send with a CID but does not wish the server to use one when sending. ... to use when sending messages towards it. A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID. FP: clarification question: I am not sure the following formulation is very clear to me: "to send with a(/the client's) CID". Could "send with" be rephrased to clarify? The previous paragraph uses "using a CID value", that would be better IMO. the record format defined in {{dtls-ciphertext} with the new MAC FP: nit - missing "}" in markdown. The following MAC algorithm applies to block ciphers that use the with Encrypt-then-MAC processing described in [RFC7366]. FP: remove "with" Section 10.1 FP: I believe you should specify 1. what allowed values are for this column (i.e. Y or N, and what they mean) and 2. what happens to the existing entries - namely that they all get "N" value. Section 10.2 FP: Just checking - why is 53 "incompatible with this document"? Value Extension Name TLS 1.3 DTLS Only Recommended Reference FP: nit- s/DTLS Only/DTLS-Only to be consistent with 10.1


Sorry, now it is uploaded to the right folder. Simple accept pull request. Thx Bala'zs


The format should be specified more clearly, by reference to a couple of RFCs The "peer" provision seems kind of awkward. For server implementations where the validation is done by a separate entity than the ACME interactions (like ), this means that the challenge no longer has all the information that the validation agent needs to do the validation. I'm inclined to drop it and put the burden on the client.


Based on , it should be made explicit that sub-group branching requires a fresh key package for each member. I think there is still a conflict of wording here that I would like feedback on because of this line (which is what triggered me thinking there was a bug)
Thanks for the PR and thanks for digging into this. I think what the sentence is meant to say is that the receiver MUST check that the members of the new group are a subset of the members of the old group at that specific epoch. Since we're using new LeafNodes in the new group and we don't have a fixed notion of identity (at least not within MLS), we have to refer to the application/the AS to ensure that the identity expressed by the credential in each LeafNode in the subgroup has a corresponding identity (i.e. one that represents the same party) expressed by a credential in a LeafNode in the original group. Maybe something like: This leaves the possibility of a collision, where the identifiers in a given leaf in the new group would be valid updates to more than one member in the old group. This should probably be forbidden in general, although outside of this case it's not really a problem, because updates are always specific to one leaf. Alternatively, we could somehow include LeafNodeRefs that specifically indicate which member represents which other member. Or just leave it up to the application to sort this all out.
Curious what you think about saying the the credential has to be equal? We can determine equality of the credential itself just by doing tls serialization.
Sure, requiring the credential to be exactly the same would be a simple way to figure out if it's the same party in both groups. However, I can imagine that some applications will want distinct credentials for each group. If we mandate that credentials are the same, this would force the application to use the same credential in every key package/LeafNode. Since subgroups can potentially be branched at any time and in any group, all key packages that a party publishes then have to have the same credential as all of the groups that party is in, so another party branching a subgroup can get hold of a KeyPackage with the same credential as the group the subgroup is branched off of. Personally, I'd prefer asking the application to check that the identities of the new group are a subset of the identities of the original group.


I can see that being an issue, although I am somewhat worried about us not being opinionated in same way about how to determine equality here, mainly because of interop type things. We punt on how to validate the credentials as well in general so I guess this is in line with prior decisions
Hey NAME and NAME check the change I just posted. NAME and I put that together, it's a bit tough to get a generic definition of equivalency.
There is currently a logical flaw in the subgroup branching flow. In order to branch, you need to compose a message . A Welcome message includes which is defined as follows: The problem with this is that the field of type cannot be made for existing members of the group because the leaf nodes are now types. is now only used to add new members to the group, so we can't reuse this for sub group initialization.
I'm not sure I understand correctly. Are you suggesting when branching a group off of another group, one re-uses the leaves of the old group? If so, that's not how it's meant to work. The new group created in the process of subgroup branching should be independent from the "parent" group safe for the PSK, which all member have to provide upon creation of the group. In fact one should never use the same key material in the leaves of multiple groups except when the supply of key packages that a party provides via the DS is exhausted (see Section 17.4).
That was part of my question. When there were key packages in the leaves, you theoretically could fork the group from a given point in time and reuse the current tree, but I wasn't sure if that was a proper solution or not. Sounds like it isn't, but either way, I think there should be clarification in the document about this. Let me write up a quick PR on it.
NAME opened URL Would like your feedback there. We have conflicting wording here as well. What threw me off in the first place was the line indicating that LeafNodes should be the same in the sub-group, and if we are fetching new key packages they will not be the same.
NAME Konrad, could you safely derive new keys for the members of the subgroup instead? If so, that would be an enormous increase in efficiency and (especially in the federated case) make group creation timing consistent enough to do dynamically.
NAME Nice idea!


But it's tricky, since we're dealing with public key pairs that the creator of the new group doesn't know the private keys for. If we were only using HPKE schemes that support updateable public key encryption, the creator of the new group could indeed update the key in the existing group and send the "delta" encrypted to each corresponding member (which would still represent an overhead, but we might be able to optimize this somehow). This is similar to the RTreeKEM mechanism that NAME et al. proposed at some point. To go all the way here, we'd have to do the same for the public key material in the credentials as well, which is not something we had considered before. It would be a new primitive, something like an updateable signature scheme? Probably something to consider for HPKE/MLS 2.0. We could also allow the re-use of LeadNodes for this particular case. It would be the simpler solution and I don't think it would be catastrophic, since we have to assume that LeafNode (or KeyPackage) key material is re-used in the "last resort" scenario anyway, but this would definitely be something we should discuss on the mailing list, as it would break a pretty basic assumption we've made until now.
Just catching up on this. NAME nice catch here. It seems like we have two options here: Require new KeyPackages (as in ) Invent some way to make a new group based on LeafNodes alone I probably agree that we should do (1) in the short term, but (2) also has some appeal -- it doesn't feel right to require new KeyPackages for folks you're already in touch with -- despite it probably being more spec text. So here's a sketch of (2) in the interest of completeness. Suppose we defined a message of the following form: ... which would pretty closely parallel to Commit. You would send it in MLSMessage and require a in MLSMessageAuth. Where Commit instructs the recipient to create a new epoch from the current one within the same group, Branch would instruct the recipient to create a new epoch that is the first epoch of a new group. In both cases, you would form an epoch / GroupContext as specified, then use the to ratchet into the new epoch.


I'm pretty sure that would work and have the expected security properties, though obviously formal analysis would be appreciated. The main awkardness that occurs to me is that any members joining after the branch would have to provide new key packages. And obviously, it would require a fair bit more spec text. All that said, though, the exercise of working all that out has increased my impression that we should do (1) for now. If we want something like (2) later, it can be done pretty cleanly in an extension.
Fixed by
Well put!


This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.


reformulated the TCP point, addressed security with a reference to -qos.
From Ben Campbell's review:
Second point is fixed by . I'm not sure the third point is an improvement.
SSL is used exactly once, as part of the acronym "TURN/SSL". This is also the first mention of TURN, but the second was much more convenient to attach the expansion to. Given that it was so awkward to attach them, I included a new section listing the "used protocols" instead.
From Magnus Westerlund in IETF LC: Section 8.1: [I-D.martinsen-mmusic-ice-dualstack-fairness] Martinsen, P., Reddy, T., and P. Patil, "ICE IPv4/IPv6 Dual Stack Fairness", draft-martinsen-mmusic-ice- dualstack-fairness-02 (work in progress), February 2015. Can be updated as this is now an WG item in ICE.
Updated in
Fixed by
I have reviewed this document in preparation for IETF last call. It is in good shape and I have requested the last call. While the last call is ongoing, I would like to double-check that this document (particularly Section 4) raises no new security considerations that should be documented in Section 6. I'm wondering if there are scenarios where a malicious application could try to game the priority scheme to some ill effect? draft-ietf-tsvwg-rtcweb-qos talks a bit about this, so I'm wondering if anything needs to be said here. And I found a couple of nits to be resolved together with any LC comments: Sec 3.2 - Please update the citation to point to draft-ietf-mmusic-ice-dualstack-fairness-02. Sec 3.4 - "Third, using TCP only between the endpoint and its relay may result in less issues with TCP in regards to real-time constraints, e.g. due to head of line blocking." This is awkwardly phrased. I would suggest something like "Third, using TCP between the client's TURN server and its peer may result in more performance problems (due to head-of-line blocking) than using UDP."


And one bit I left out — if text is to be added to reference draft-ietf-rtcweb-return, that should be done together with addressing nits and LC comments.
There seems no consensus to add RETURN, so I'm skipping this for now.


Éric Vyncke said:
I think the ambiguity is whether the "limited to" is saying: the maximum datagram size is no more than twice the maximum datagram size (which is nonsensical) the initial congestion window is min(10maxdatagramsize, max(14720 bytes, 2maxdatagramsize)) Given that one of the possible interpretations is logically inconsistent, the other one must be correct. I'm not sure how to make this sentence clearer except through pseudo-code. Looking at the pseudo-code, there isn't any -- kInitialWindow is declared to be a constant, value defined by this text, but the definition of this constant is given in terms of a variable (maxdatagramsize). Maybe kInitialWindow should become a variable itself, and then have pseudo-code with the max/min relationship added to B.3?
This is clearer; thanks.


Start collecting changes from AD review
Comment by NAME : /example value 4711 not actually registered like this:/ ~~~ I don't get the sentence above - if this is to highlight that this is an example and that the value 4711 is not actually registered, I think this is redundant (and you could also add that in the Figure caption rather than in the example's text).
See : The danger that people are just blindly copying an example is just too high. So we would prefer to keep this redundant comment in. We could improve the wording of the comment.
Comment by NAME : Please explicitly state that the example (or examples if you add one in ) uses CBOR diagnostic notation.
Fixed in .
Closed by 7463ce1


In the "Specifying Endpoints" section, added a reference to the Selection Property that does a similar thing but with more fine-grained control. It wasn't clear to me what is the best place to add this, so I put it right below the first example of specifying an interface name for the Local Endpoint to say that you can also do it differently. If you have better suggestions, please let me know. To the ListenError and RendezvousError, I added text mentioning the "reconcile Endpoints and Properties" pitfall. I think this is probably more general, i.e., there might be more sources of errors than just local interface, so I kept it generic.
For Local Address Preference we only have the option to prefer stable or temporary. However, I guess we would also need a way to e.g. specify that stable is required, no?
Is this addressed by PR ?
I don't think so.
When reading the current API draft, I was wondering the following: If an application wants to specify one or multiple local network interfaces, it can either set the Local Endpoint(s) or it can set the "Interface Instance or Type" Selection Property. I think both ways are valid and should exist, but I'm wondering if we should specify anything on the interaction of these two ways to do a similar thing. For example, should we explicitly mention the Selection Property in Section 5.1 ("Specifying Endpoints"), to make readers aware that there is a "better" way to do this, which allows more flexibility? Also, if an application specifies conflicting things, I guess this leads to an InitiateError, ListenError, or RendezvousError. Our current text already says this for the InitiateError: But should we make this particular issue more explicit here and/or should we add it for the ListenError or RendezvousError?
I think so, yes! Regarding the error in case of a conflict: I think so, yes - to all your questions: make it more explicit, state it in the description of both the ListenError and RendezvousError. Just my 2 cents
Thank you - works for me!


Addresses Martin Stiemerling's TSV-ART review
Merging based on NAME review
On the mailing list, Rifaat Shekh-Yusuf pointed out these issues: Section 7.3.5, first paragraph, second line: A "bind" word is missing between the words "to" and "an" Section 7.4.1, second paragraph, second sentence: "case" should be "cases". When the server builds the authorization object, the document is stating that the response would include "challenges" and "combinations". Remove the "combinations" as it is not being used. Section 7.5.1, the Request URIs in the examples: Should not this be /acme/authz/1234/0?
In "Responding to challenges," we use the term "response fields." These fields are defined by each challenge type, but are not described as "response fields" there. We should add a heading describing them as such in the challenge type definitions.
The other challenges don't expect you to post a payload containing a type field, so it's inconsistent for OOB-01 to do so. It should just take an empty object "{}" as its payload.
This seems fine. It seems to be protected from replay by the and parameters. I think we're OK leaving the challenge name at "oob-01", since this isn't a breaking change.


The "using https:// URIs" part is just odd. Easier to simply state that this uses HTTPS at this level. Also, if the concept of a DNS service evolves to encompass other types of exchange than simple request-response, then "run DNS service" won't be accurate.
I added "DOH" to the title because it was now being removed from the Abstract.


Interface, Section 2, "A unified interface to datagram and connection-oriented transports, allowing use of a common API for connection-establishment and closing". Should this be "…to datagram and stream-oriented transports"? At what point do we explain that and are also used for connectionless protocols? This change would finesse the question here, leaving it for Section 3, or we can restructure the draft to clarify earlier.
Yes to (1): Datagram protocols can be connection-oriented or not; however the point here seems to be either: /interface to datagram and stream-oriented transports/ or /interface to both connection-less and connection-oriented transports/ ... I'd favour the first, it's clear enough and doesn't use terms that we later re-use. Also to (2): I think we could insert a specific sentence after: " A Connection represents an instance of a transport Protocol Stack on which data can be sent to and/or received from a Remote Endpoint (i.e., depending on the kind of transport, connections can be bi-directional or unidirectional). " That explicitly says something like: "This connections are presently consistently to the application, irrespective of whether the underlying transport is connection-less and connection-oriented."


I think this is good to go, will plan to land at EOD.
Does it obfuscate, conceal, or obscure local IP addresses? My vote is for conceal.
Conceal/concealment sgtm.
As noted in , we don't need to use the same term in every case, but the terms should have the same meaning. conceal and hide are fairly synonymous, but conceal and obfuscate have slightly different meanings.
This section is largely normative, so it might make more sense to put some parts from it immediately after Principle, namely the various adjustments to the technique that need to be considered (TURN, IPv6, stats) Things where we merely provide discussion (e.g., session monitoring) rather than normative guidance could remain in the privacy section.
Due to their different sensitivity and lifetime.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private?


If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
The rest LGTM


NAME Good point about being more explicit. I actually think is valuable to reference an existing encoding of public keys providing also key type and curve, like CREDX in URL Also, there is a discussion about format for public keys in COSE, which if it is specified probably will be referenced by EDHOC instead of CREDX. I would be good if there is a common format used in all these instances. For the time being I propose that we reference CRED_X with empty text string subject name, and keep track of the COSE activity.
We should consider replace the NIST reference with SECG [1] to harmonize with EDHOC [2]. [1] URL [2] URL (edit) ... but the commits in [3] mainly refers to the NIST spec. so I propose we keep it as is for the time being. [2] URL
It looks good to me; we can give more details on one point. For the two HKDF invocations in Section 2.3.1, we can define more explicitly how the public keys are expressed when concatenated to form IKM-Sender and IKM-Recipient. Given a public key, that can simply be: For OKP signature keys, the compressed 'x' coordinate, i.e. what would be expressed in the key parameter -2 of a corresponding COSE Key. For EC2 signature keys, the 'x' coordinate followed by the 'y' coordinate in this order, i.e. what would be expressed in the key parameters -2 and -3 of a corresponding COSE Key. This should be sufficient, i.e. it shouldn't be needed to have a more structured encoding of public keys providing also key type and curve, e.g. like done for CRED_X in URL


, requires transport stacks to support abrupt closure of a stream even after the stream has been cleanly closed. This reflects the possibility to transition from "Data Sent" (stream has ended) to "Reset Sent" by sending a RESETSTREAM. Based on the state diagram in the transport doc, if an implementation was already in the "Data Recvd" state, they wouldn't actually send a RESETSTREAM, as they're already in a terminal state; a reset call would be a no-op or an error of some kind. However, NAME points out that in a handle-based API, this essentially means that handles for closed streams have to be recognizable as such for the lifetime of the connection. This might be burdensome for some implementations. Should we reword the requirement here to say that it's permitted if the stream hasn't yet reached the "Data Recvd" state.
This was clearly just a miss on the wording. I don't think that the intent was ever to require that streams be kept around indefinitely. Sure, some stacks might be able to send RESET_STREAM at a whim, but it's not necessary


This text does not address who might be allowed to wait for the other guy to make their statement (if both wait, there is a deadlock).
The intention is that neither side needs to wait. The only open issue is whether we want to allow the client to immediately start sending messages after it sends its CSM without waiting for the server CSM similar to the HTTP/2 case. I planned to discuss that on-list when I "advertised" this set of pull requests.
From your message I understand that in HTTP/2 the client can send messages immediately without waiting for the server to respond either. To me it feels like we should be doing what has been done in the HTTP/2 case even though there is a risk that some problems occur when the client sends data in way that the server will subsequently not handle well. If that is the case, the client will have to re-send the data, I guess. For the currently defined options I don't see problems.
When I submitted the original pull request, I also posed a question on the but did not receive a response. One open question is whether we want to allow a client to immediately send messages after sending its CSM without waiting for the server CSM. This would be similar to HTTP/2: URL To avoid unnecessary latency, clients are permitted to send additional messages to the server immediately after sending the client connection preface, without waiting to receive the server connection preface. It is important to note, however, that the server connection preface SETTINGS frame might include parameters that necessarily alter how a client is expected to communicate with the server. Upon receiving the SETTINGS frame, the client is expected to honor any parameters established. In some configurations, it is possible for the server to transmit SETTINGS before the client sends additional frames, providing an opportunity to avoid this issue.
I support not blocking the device until the server CSM. The server can choose to not process messages that are invalid (e.g. too large) and immediately follow up with the server CSM. From the perspective of a cloud and gateway software provider, the CoAP (using TCP/TLS) server will usually be in the cloud or gateway and therefore usually not power constrained. I may be missing other scenarios where a battery powered device is acting as a CoAP/TCP server. Does anyone have plans for any of those scenarios?


NAME added a related comment to (which is closed) From your message I understand that in HTTP/2 the client can send messages immediately without waiting for the server to respond either. To me it feels like we should be doing what has been done in the HTTP/2 case even though there is a risk that some problems occur when the client sends data in way that the server will subsequently not handle well. If that is the case, the client will have to re-send the data, I guess. For the currently defined options I don't see problems.
Michel Veillette points out that a peer that wants to use a new connection has an uncertainty whether a CSM message with capability indications will come or not, so it is hard to decide when to send the first request (either based on default capabilities or waiting for the CSM to come in). One way out of having to do arbitrary waits would be to require the exchange of a CSM message (even an option-less one) after connection setup. The burden is very low, as a minimal implementation would just need to send a constant message of 0x00 0xe1 at setup. This requirement could be stated without giving a sequence, effectively allowing both sides to send the initial CSM in parallel, or it could give the listener the opportunity to not send its CSM until the connection opener has sent theirs, trying to avoid the need to answer right away to a connection setup -- this makes it too easy to scan for ports (OK, we also have a default port, and making scanning harder does not by itself provide any security, but it sure makes life a little harder for the attacker). (To avoid deadlock, the connection opener would not have the opportunity to wait sending the CSM.)
+1 ... especially for Maximum-Message-Size. HTTP/2 has a similar flow for SETTINGS during connection including potentially empty settings: URL URL
No objections. I will create a pull request for review by the WG.


sig-02 did not define the length for options with uint values. Can you confirm whether 0-4 is correct? I note that there are variants in the RFC7252 options with uint values.
Good catch. 0-4 definitely is right for Max-Message-Size. 0-4 is a bit over the top for Hold-Off, but arbitrarily limiting the time at, say, 65535 seconds (0-2) or 16777215 seconds (0-3) doesn't sound right either -- well, maybe half a year max (0-3) is about right. Option numbers are 65535 max, so Bad-CSM-Option needs to be 0-2.


LGTM
Hubert Karlo writes: And how does the client know that the algorithms came from the server. We should have a "client MUST wait for the full handshake to finish before recording this information" or we will have a very nice cipher downgrade. Just having it signed is likely not a good idea, as they may depend on ciphersuites advertised by client.
Since the ServerConfiguration and the suites are covered by the signature the server provides, isn't it safe to use the configuration add soon as you have verified the server identity?
n.b., I have no problem with mandating that clients wait for finished, because it is immediately after the signature, but I wasn't the properties to be clear.


This is a reworking of the text from Section 4.2 of draft-trammell-taps-post-sockets-03, intended to help motivate the choice of Message-based APIs with framing for the transport services architecture. The level of detail here seems appropriate for the architecture document, rather than the API.
Well written, NAME
What's convenient about the framer? If I have messages of 100 bytes and the length is what defines my message, what's the point of requiring me to define a framer function that I give to the system? I just send, send, send, off go 3 100-byte messages. Hard to get more convenient than that :) I understand that the hook to a sender-side and receiver-side framer can allow you to offer a library that does framing when needed; I don't personally see this as a big win, but okay... and I understand that forcing apps to use a receiver side de-framer can, in principle, let us do cool things on the receiver side (accessing messages out of the bytestream). But for sending this just seems to be an uncomfortable add-on. I guess I shouldn't be arguing it as somehow it's again just syntactical sugar, and I said before that I don't care too much about syntax here. I get it, for the 100-byte messages the framer just won't do anything, and for sending I have to use Connection.Send(Framer.Frame(Message)) instead of Connection.Send(Message)... these calls could basically be renamed into SendMessage vs. SendSomethingHuge. I said before that I don't care too much about these syntactical bits. I guess it's just that tying "Connection.Send(Message)" to "we assume your Message is big and terminates a TCP connection" is really counterintuitive to me.
... and I think I answered to NAME in the wrong place :( sorry github
NAME what’s convenient about the framer? In a C based implementation, very little. In a high level language implementation, however, it means I can and have it convert the high-level structured data into the on the wire format automatically, using a reusable library.
no, no, that was right. Framers can take an object by reference or value of any type, and turn them into an appropriately framed octet array. Syntactic sugar, yes, and pointless in some languages.


But have a look at URL -- here, you're pushing down the thing that converts application structures into wire structures into the API, so the API speaks to you in terms of your own structures (in Go, this is generally called a ; IIRC from Java is the terminology there). If your application-internal structures are already serialized byte arrays, you're right, there is zero win here.
NAME Framers are still very very useful in C. You can use callbacks, function pointers, etc, to help lay our your data, and doing that in the context of the networking thread improves efficiency (beyond the simpler API).
NAME even better, then!
also: so this whole line of argument is extremely perplexing to me, and indicative of some sort of fundamental failure to communicate on this particular point. absolutely nobody is saying that this interface implies "your Message... terminates a TCP connection" on the sender side. I can't see where you're getting the impression otherwise in the text. (When receiving, yes, if the receiver has no way to deframe the stream, you get a message that never ends, as a series of partial reads that looks just like a bunch of calls on a stream; i.e. when it fails, it fails to something that basically works exactly like sockets with callbacks.) I really suggest we table this whole discussion until London, because we don't seem to be making much progress in here, and ask you to trust me until then when I say that there is never, ever, ever a situation in which an implementation of this interface that was actually working would ever look at a single message on the sender side "oh, cool, that's done, guess I'll send a FIN then!", ever, because that would be an incredibly silly thing to do. (where's the blink tag in github markdown? i really need the blink tag for this)
On this: Sorry, there's a lack of context - I interpreted this out of private emails from Tommy, which seemed to pretty clearly say that, if you just call "send" without providing a framer, you do send a FIN - and I just found that awkward. But heck! Clearly we all don't want silliness to happen and we want a nice clean interface, and clearly we can quickly agree on this in London. So no worries, and see y'all soon!


Addresses . NAME points out in that we use in the transport draft and in the recovery draft. In reading carefully, I realized that in the transport draft was actually historical, and is the more appropriate term. This is an entirely editorial PR, and it's largely simple changes, despite the fact that it looks a bit big. It is a bit subtle though. Sorry about that.
This issue will list a number of minor editorial things that should be checked and likely addressed with some editorial fixes: Section 5.3: "These delays are computed using the ACK Delay field of the ACK frame as described in Section 19.3 of [QUIC-TRANSPORT]." This text implies that the computation of the delay is described in Section 19.3 of QUIC-TRANSPORT. However, I don't think it is described the calculation, only the definition of the field. Please reformulate to imply only field definition not calculation. Section 5.3: "On the first RTT sample for the network path, that sample is used as rttsample. This ensures that the first measurement erases the history of any persisted or default values." I think this intended to cover cases where path changes are detected. But it is not well expressed. Does this need a reformulation and a reference into QUIC-TRANSPORT where it states when such a reset should occur? Section 6.1: "Either its packet number is kPacketThreshold smaller than an acknowledged packet" Nitpicking, assuming no PN gaps in transmission. Does that need a note? Section 6.2.4: "An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram or transmit data from multiple packet number spaces." This last part, I assume intended to generate additional datagrams to prevent single loss to impact. However, due to coalescing this is unclear in this context. Section 7: "Endpoints can unilaterally choose a different algorithm to use, such as Cubic ([RFC8312])." I think this sentence should be explicit that in needs to be sender-based algorithms. I think we need to have the requirement on performing congestion control on the sender unless there has been explicit agreement with the receiver that they will do it.


Section 7.2: "Endpoints SHOULD use an initial congestion window of 10 times the maximum datagram size (maxdatagramsize), limited to the larger of 14720 bytes or twice the maximum datagram size." "maximum datagram size" is not used in Transport there need to be alignment here of what name to use. Transport has Maximum Packet Size, which appears to match the definition in the appendix of maxdatagram_size.
Thanks for your careful review, NAME -- these are good finds! I've addressed your comments below and in . I'll address point 6 in a separate PR. Section 19.3 has the following text, which does tell how to compute acknowledgement delay from the ACK Delay field: I've replaced "computed" with "decoded" in the recovery document to make it clearer. Coalescing applies to packets, not to datagrams. We've explicitly stated that a sender could send 2 datagrams to avoid any effects of coalescing. I think the text is pretty clear on this: "An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets". I've added "sender-side" to make the controller more explicit. To your point about making this a sender requirement, that is covered in the transport doc (end of ):
Based on and , labeling this as "editorial"
I think these issues are resolved once the two PRs are completely ready.
Except for the one erronous exchange of packet this looks good.


For discussion.
See also: URL
I proposed on the mailing list to remove implicit renewal some time ago, and it received some support. Creating this issue to track it. All discussion should be done on the mailing list.


This was never explicit for the client as it is usually not possible. in a way that perhaps was not anticipated.
is complete. Consequently, a server might expect 0-RTT packets to start with a However, this is not necessarily strictly true, because you might have the ACKs in 0.5RTT. Now you might say that the TLS stack reports the handshake as complete as soon as it receives Finished but that's an implementation detail
I think that this is true. The server can send before then, but we require that the client not install 1-RTT keys until it considers the handshake complete.
That's not entirely true. It's the server that needs to hold back keys (namely, the 1-RTT read key) until the handshake completes. The client can use keys as soon as they become available.
I think NAME is correct in sense that the following three events happen at the same moment on the client side: handshake is declared complete TLS stack provides the 1-RTT read and write keys TLS stack provides ClientFinished
Martin is correct. There are two different forms of handshake completion: complete when 1rtt can be sent and received, confirmed when the peer is known to be complete. The client cannot receive 0rtt acks before installing 1rtt keys, hence before hanshake is complete.
a nit, but LGTM


Starting to address This is an early review, to check if we like the structure. I'd also like help filling out the SCTP section!
I can also help with SCTP, which I would do in the same style that I suggest above (for TCP, in my example of "Abort") - also later.
We've updated Implementation mapping details for most protocols with , but we didn't tackle SCTP yet.
I'm fine with this being assigned to me. However, it's more than just writing the SCTP text. Here's the relevant part of what I wrote in PR : I don't suggest to delete much of the text that's there but definitely amend it with the RFC reference at least for what's covered in RFC 8303. There's a very direct line from this type of text in RFC 8303 to the original specs, so I do believe that should be helpful. That's (obviously) post-Montreal though!
NAME please send a PR along these lines.
LGTM modulo mwelzl changes.I think this is a good step forward. This said, I think we should describe things focusing on the transport's API call to be made (in line with the spec - that's why we have RFCs 8303 and 8304) rather than protocol internals. E.g., rather than saying that Abort on a TCP connection transmits a RST, I think we should simply say that Abort calls ABORT.TCP [RFC 8303, Section 4.1]. I can take care of these things, later. I'd still like to focus more on the API doc at this time.


All expected to be uncontroversial; to be merged soon.
Commit 3809be46013e9708a6584c4fb730e7cfecab5f22 should have been part of this as well, and is already applied to master.


We're talking about the key wrap function here. Of course there's a requirement to remove padding, but it's explicitly clear in the AES Key Wrap RFCs. Seems like this text might be wrong now.
Thinking about this a bit, I think I will redo to just make it so decrypt has to remove the pad - I think this is way hold historic text that makes no sense given we use key wrap
Section 2.3 The decryption function returns a plaintext value P that is at least M bytes long, or returns an indication that the decryption operation failed because the ciphertext was invalid (i.e. it was not generated by the encryption of plaintext with the key K). These functions have the property that D(K, E(K, P)) = ( P concatenated with optional padding) for all values of K and P. Each cipher also has a limit T on the number of times that it can be used with any fixed key value. The EKTKey MUST NOT be used more that T times.
I think the goal was to avoid having a length indicator in the encrypted data as the stuff outside this knows the size (and thus how much pad to remove). Thoughts on what we should say here in the draft ? NAME NAME
should we clarify, how the code knows the length of the padding on the decryption side ?
I'm unsure what the question is. I reviewed that section of the current draft and it sounds clear. Perhaps the confusion is over the padding? The AES Key Wrap logic defines how to insert and remove padding. You can see how that's implemented here: URL There is a "with padding" function that inserts required padding per the RFC. So, what's the question?
NAME .. I think the question is on clarifying when the padding gets added and removed. Is it out of enc/dec or inside. We might just need to clarify tht
It's defined in the RFC. I don't think we should be trying to explain it again here.


Fix to Issue
We don’t mention layers in the text before: “A violation of any of the layers should cause” Is this better as: ” A violation that occurs at any of the policer layers should cause”
Fixed


Updates token introspection definitions into a more full protocol offered by the AS.
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: 0b6505e11547ab68388ce27ffc88a8e1c9e5c16b :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Introspecting a Token: Editor's note: This isn't super different from the token management URIs, but the RS has no way to get that URI, and it's bound to the RS's keys instead of the RC's or token's keys.
From a privacy point of view, token introspection allows an AS to know exactly when operation(s) are being performed by an end-user on a RS. This provides useful information for ASs that may be tempted to act as "Big Brother". For that reason, the risks related to token introspection should be advertised in the Privacy Considerations section. Its usage should be deprecated in the general case. If there exists specific cases where there is no such a risk, these cases should be advertised.
The section doesn't provide any information on what happens when a client wants to introspect an inactive/invalid/revoked token.
Yes, this is pretty thin right now. It's the RS that introspects the token, and this section will be pulled out into a separate spec to make that more clear (). The response for both positive and negative situations is likely to be based on the OAuth introspection spec, RFC7662 URL
We should add: the AS MUST validate that the token is appropriate for the RS that presented it, and return an error otherwise.
In OAuth token introspection, the AS doesn't return an error in this stated case -- it simply says the token presented is not active, in order to prevent information leakage to a nosy RS.
NAME I don't understand your argument about a "nosy RS". The text states: As a consequence, if the AS does not recognize the signature, it can return a error stating "bad signature". If the signature is correct, the AS can provide all details to the recognized RS, as yaronf mentioned.
s/error/inactive status/.
Token Introspection: it is not clear to what depth we are defining the API: is it only the existence of the "introspect" endpoint?


Or do we define a minimal set of standard attributes that need to be returned? The API would not be useful for interoperability unless we define some of the returned attributes. At the very least: "active".
The idea would be to define a core attribute set with extension points like RFC7662. This same attribute set could be used for the token model (but maybe not format?) described in


This is the way we've been treating this, so let's acknowledge that.
As I noted on the list, I don't think this is correct. I proposed alternate text.
Still LGTM. :-)


This adds an XML example. The only question is whether we need a prefix for ietf-https-notif in the example.


I assume the intention was to forbid the same setting identifier occurring multiple times in a SETTINGS frame, regardless of the values. However, since a parameter is defined as an identifier-value pair, the current text does not forbid duplicate identifiers if the values are different.
An alternative below. But this is good either way.Looks fine to me, modulo the line length.


From Gorry's review.
Gorry suggested that the QUIC recovery draft should specifically recommend against packet reordering thresholds less than 3 because it will not be sufficiently tolerant of real-world reordering. Pull already created.
FWIW, I think this is likely design because it adds a SHOULD NOT, but it also doesn't substantively change the existing recommendation.


If the Retry token is known to be invalid by the server, then the server can close the connection with INVALID_TOKEN instead of waiting for a timeout. Came out of discussion of Issue Related to
You need to update the "Transport Error Codes" section too.
Thanks NAME I did that in a subsequent update. Refresh and tell me if it looks correct.
NAME you're missing the section that gives some text to each error code .
NAME do you have a suggestion about what the client should do? Clearly it could start a new connection, but it would't want to do that an unlimited number of times, and it may depend upon whether a TCP fallback is available. Given that, it wasn't clear I should recommend something. And I agree making them distinguishable should be a MUST, as stated in
I think that the best thing we can say is "the connection attempt failed". The first version of the PR strongly suggested that making another connection attempt was the right thing to do, but that gets into lots of difficult questions about identifying why. Given that this is an error that only happens if a Retry is spoofed, then I think that all we can say is: !
When the server receives a Token that is corrupted, it may want to close the connection quickly. This issue suggests adding a new error code to indicate the token is corrupted, INVALID_TOKEN.
This is - I believe - a design issue. The PR seems to have approval, we just need the appropriate process run.
We currently say that these tokens SHOULD be distinguishable by a server on the basis that an error in a NEW_TOKEN token is recoverable, but an error in a Retry token is fatal. I don't see why this can't be MUST. If we make it "MUST", then we can rely on this property in the design.
Agreed, that'd be a useful property to rely on.
Does that property need to hold if there are bit flips in the token? If you’re encrypting the token, this would be easy to ensure: put the distinguishing bit under crypto cover. If you’re using a map lookup, you’ll probably have to work a little bit harder.
Please ignore my last post, I mixed up Retry packets and Initials. Tokens in the client’s Initial are part of the AAD, so we don’t have to worry about bit flips.


Depending how the server distinguishes them, a change of method / confusion about what server you're sending it to could make you appear to be presenting a Retry token instead of a regular token. This error code enables the client to recover and retry quickly, but there's no language about what the client should do when it receives the code.Rereading the changes, I have the following editorial suggestion.


EKR entered the following DISCUSS: Your citation to ICE is to 5245-bis, but at least the JSEP editor consensus was that WebRTC depended on 5245, so this needs to be resolved one way or the other.
Sean asked me to leave this one open. Personally, I'd somewhat prefer to 5245bis because it separates out the SDP machinery, but JSEP has a specific section reference (section 15.4) that has to go to either 5245 or to mmusic-ice-sip-sdp, and one could argue that we need to pull in -sip-sdp here too. I'm OK with 5245 as a reference, but will let the chairs make the call.
I no longer care about this distinction.


A proxy can receive a UDP packet from an origin to a client that cannot fit within a DATAGRAM frame, given either the limit set by the maximum datagram frame size, or based on the current path MTU. In this case, one solution is for the proxy to generate ICMP errors back to the sender. If that sender implements PMTU discovery, it should adjust its size.
I think adding advice here is good, though we can't mandate sending ICMP because most OSes don't let user space applications send ICMP.
Yes, we can't mandate it, but we should recommend it I think. For a full-blown production server, it should be possible.
Recommendation seems sensible. Although this does get me thinking about what the expectations of fragmentation are, we can't expect all UDP protocols to set DF.
The DATAGRAM capsule type offers one way to address this. Capsules can be arbitrarily large, because they'll be reassembled by QUIC. If it won't fit in a QUIC DATAGRAM and you don't want to drop it, it goes in a DATAGRAM capsule. Now, that might not always be desirable, because capsules don't have all the behavior that causes you to choose datagrams in the first place; a proxy that behaves that way will mess with PMTUD, and in the degenerate case cause the server to select an MTU back to the client that always gets encoded in capsules. Perhaps the client should be able to inform the server whether it prefers oversize messages to be tunneled or dropped?


Provisional answers, on the other hand, do no such deallocation results as a result, multiple dissimilar provisional answers can be received and applied during call setup.
Fixe by


As discussed at the F2F meeting at IETF94, MAC-based account recovery is not adding a lot of value, and it adds significant complexity to the spec. (And nobody has implemented it.) This PR removes MAC-based recovery and the crypto that it depends on.
Seeing no complaints on the mailing list, merging.


Provides more context around the various elements of the model
Thanks a lot for your stab at Security Considerations! Also the I-D was in dire need for some expositional english text. Reads straight forward and comprehensive.


Is this strictly necessary?
You're right, it's unnecessary and doesn't add anything. Removing via .


The draft states that Shouldn't be the result 6b2611489cba2b63a9e873e2 instead of 6b2611489cba2b63a9a873e2?
Yes, I submitted PR for this issue.


draft_eddsa is now . sandj-tls-iana-registry-updates is now ietf-tls-iana-registry-updates.


It makes sense that we do not talk about creation time of the content. However the concept of having a time in the header is also very reasonable for things like countersignatures where one wants to make a timestamp as there is no content that the time marker can be placed in. We therefore change the text to make the time field be the time that the cryptographic operation was performed at.


In the last paragraph of section 8 at "programmer MUST recognize". That is not an appropriate use of 2119. I suggest "needs to be aware" instead of "MUST recognize".
This seems right


uses http-core semantics fixes Sections refs cc: NAME
I'll wait for the new i-d-template image, but will do.
Please use either [RFCxxxx], Section yyy or Section yyy of [RFCxxxx]
Addressed by now.
If you start using the new kramdown-rcf2629 section ref syntax, you may want to do that consistently...


This is much more compatible with extensibility patterns in TLS stacks, and in a way that is very forward-compatible with the forthcoming DTLS 1.3, while still being implementable in pre-1.3 stacks. DTLS 1.3 has a notion of post-handshake handshake messages, like and , which are acknoweldged with an message. The framework described here simply sends as yet another post-handshake message. Depends on
r? NAME
I have a bunch of comments but really I could live with this like you have it now.


Originally raised by Christer Section 3.2 says: "JSEP also allows for an answer to be treated as provisional by the application. Provisional answers provide a way for an answerer to communicate initial session parameters back to the offerer, in order to allow the session to begin, while allowing a final answer to be specified later. This concept of a final answer is important to the offer/answer model; when such an answer is received, any extra resources allocated by the caller can be released, now that the exact session configuration is known." 1) I would like explicit text saying that this is a deviation from RFC 3264, where there is no such thing as a provisional answer. I would like to have a dedicated ³Deviations to RFC3264² (or something similar) section. 2) I would like explicit text saying that the final answer may be completely different (in terms of candidates, codecs, accepted m- line etc) from the provisional answer. 3) Related to 2), the final answer may also require NEW resources to be allocated.
We discussed this and we don't think text is needed for 1) or 3); the offerer doesn't release resources until the final answer. For 2), what kind of text did you have in mind?
Few notes to cullen from talking wtih Christer Christer proposals ... adding section "SDP Offer/Nswer Usage" document variation we make on SAVPF stuff explain how ANSWE / PR answer are used withen paringin multiple to single offer Points to section for details ... follwo proccedures in 3264
Cullen, I think I improved this. PTAL


Re SNI and ALPN: we can certainly point at the work in progress in TLS that will encrypt this information, but IMO the document should describe the current state of the world. I've just added something pointing to the SNI encryption document; while it seems that the tunneling technique described there could pretty clearly be applied to ALPN fronting as well, is there a reference for encrypting ALPN we can use here that doesn't leave details as an exercise for the reader?
I would actually prefer to describe the wire image of TLS and associated protocols in a separate document and just point to it because that's actually not only applicable for quic
I don't have a reference for encrypting ALPN. We don't have one. Maybe I should write one... On the plus side, it's something that benefits from the same techniques as SNI (and less likely to cause deployment issues, though that is only because we haven't ossified around it as much). As for the general point about now vs. later. One of the things we've tried to do is be very clear about what the invariants are, or what promises we are making. It's not the same thing as true ossification defense, but if we make it clear what we are committing to, maybe we won't have people relying on stuff we might want to change.


When we banned client auth and PSK, we only meant to do it for the main handshake, not the post-handshake phase. This reverts that change, as well as clarifies the prophibition on PSK plus cert-based auth.


Signed-off-by: Dave Thaler
` Isolate? From what? “Isolation” seems to be used several times in this and later sections without saying who’s isolating what from whom.
I don't understand that sentence either. Propose removing it. Another sentence: Propose removing "isolation and" Other uses of isolation I think are fine, where it means that an Attesting Environment cannot be modified by a Target Environment it measures. Any way of protecting that might be called "isolating" the two environments from each other in some way.


This makes the choice of a 1:1 mapping clear: avoid being used as an open proxy through explicit configuration of your ACLs. cc NAME
The proxy has a fixed mapping. It's resource maps to just one request resource. That's a deliberate choice that we should probably be much more up front about.
Yes, I think this makes sense, but it took me a while to realize it when implementing. Having a section on mapping state on the proxy would be useful.
Vittorio says: This relates in particular to the potential for generic services with open destination (not a capability in the proposal) to be used for nefarious purposes (spamming, bot net command and control, hiding illegal activity, etc...).


Second paragraph of 3.2, last sentence: at "these parameters or reject them" - "these" and "them" have ambiguous antecedents. It's not clear if you are trying to point to the parameters that don't follow the earlier stated rule, or all parameters. The sentence is complex. Splitting it up and finding a way to avoid the need for the semicolon will likely make it easier to say what you mean.
I agree that this is messy. Editorial.
LGTMLG with comment


Behold
NAME I think this is inches of getting landed
The full text of that section is "TBD."
HPACK covers the following topics: Probing Dynamic Table State Static Huffman Encoding Memory Consumption/DoS Implementation Limits To what degree to we need to retread this vs referring to 7541? There are some new areas to cover related to DoS, like recommending implementation timeouts for blocking requests. Soliciting any other topics, and possibly a passionate security-minded volunteer to draft a PR.
All looks good (and familiar); some minor nits.