jiebi/CodeConvo huggingface dataset:
Code change:
fall back to some other transport protocol.  In the case of HTTP, this fallback is TLS 1.3 over TCP. <ins> The IETF TAPS specifications I-D.ietf-taps-arch describe a system with a common API for multiple protocols and some of the implications of fallback between these different protocols, specifically precluding fallback to insecure protocols or to weaker versions of secure protocols. </ins> An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS 1.3 exposes control information to modification and manipulation in the network.  Further

Related discussion:
text: NEW In the case of HTTP, this fallback is TLS 1.3 over TCP. Note that for HTTP a fallback to TCP also requires the use of a different version of HTTP, as HTTP/3 has been optimised for use with QUIC, e.g., by removing multiplexing from the HTTP layer and used the provided mechanism within QUIC. We could even add something more like: "Other applications that are optimised for QUIC might need similar adaption in order to be able to function on TCP." However, not sure that adds much... What do you think?
I'm still not sure that helps. And I'm trying not to derail Gorry's OP. The main grounding I have in my understanding is HTTP. But I appreciate the Applicability document is general purpose, so apologies. Many HTTP applications operate at the semantic level. HTTP semantics are version-independent and get profiled into versions that have a wire-syntax, which depends on different properties of a transport. This could be an optimised use of QUIC features, or it could be an outright requirement for those features. There isn't an interoperable notion of "I want to do HTTP/1.1 over a reliable in-order transport, TAPS selected QUIC for me, great I'll use that" nor "I want to do HTTP/3 over a reliable, multiplexed, in-order transport, TAPS selected SCTP for me". The transport fallback behaviour for HTTP semantics is quite straightforward. Pick a different HTTP version. This could lend itself to a race like scenario. However, there are applications that use HTTP as a substrate and things like MASQUE and WebTransport place requirements on the use of features only available in HTTP/3 - I doubt anyone will try to backport features of QUIC to TCP in order to satisfy the requirements of layers above.
I was thinking of something like: /The IETF TAPS specifications [URL] describe a system in which multiple protocols can be provided below a common API. and describe some of the implications of fall back, which specifically precludes fallback to insecure protocols or to weaker versions of secure protocols. / Perhaps inserted after this: /These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the fallback protocol./ ... and before mentioning fallback to TLS over TCP.
Code change:
fall back to some other transport protocol.  In the case of HTTP, this fallback is TLS 1.3 over TCP. <ins> The IETF TAPS specifications I-D.ietf-taps-arch describe a system with a common API for multiple protocols and some of the implications of fallback between these different protocols, specifically precluding fallback to insecure protocols or to weaker versions of secure protocols. </ins> An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS 1.3 exposes control information to modification and manipulation in the network.  Further

Related discussion:
text: NAME you are right that QUIC provides features that TCP doesn't provide and if you use those features you cannot just straight-away replace one with the other. However, a simple one-to-one replacement not implicated when talking about falling back. Rather than trying to back-port features to TCP, what you need to do is implement that feature in your application instead (as H2 does for multiplexing). But this is also true if you try to use TCP and fall back to UDP but need reliability; then you have to implement it in the application layer. I was trying to be brief in my proposed text and maybe the word "optimise" is not the right one. We can of course say more. Do you want to give it a try and propose some text if you think it would be helpful to say more?
Thanks. I'll have a think on some text. The important thing is that H2 wasn't designed as a fallback for H3, it is its own thing. There are few features that an application desires that it couldn't also achieve by just using HTTP/1.1 and multiple connections for multiplexing.
May I ask what these features are? E.g., the ability to send unreliable datagrams should not matter in the best effort Internet (reliable transfer, when not needed, is just slower). In RFC 8923, we made an effort to identify exactly what MUST be exposed to an application because there's no such fall back. This covers TCP, MPTCP, UDP, UDP-Lite, SCTP and LEDBAT; alas, it excludes QUIC, since this work pre-dates its finalization (by far, despite the date: it spent a long time in the RFC Editor queue). So now I'm curious what QUIC adds to this list.
mainly multiplexing I would say but that probably covered by SCTP
The main feature that QUIC provides to the HTTP substrate is that it is a secure transport that can work on the Internet and is easily integrated with WebPKI. These are meta-features in a way. Having parity of the deployment and security models allows more straightforward rationalisation when designing applications and e.g. Web APIs on top of this substrate.
Thanks! About muxing: is a certain prioritization behavior guaranteed (not just a wish) when muxing with QUIC?
Code change:
fall back to some other transport protocol.  In the case of HTTP, this fallback is TLS 1.3 over TCP. <ins> The IETF TAPS specifications I-D.ietf-taps-arch describe a system with a common API for multiple protocols and some of the implications of fallback between these different protocols, specifically precluding fallback to insecure protocols or to weaker versions of secure protocols. </ins> An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS 1.3 exposes control information to modification and manipulation in the network.  Further

Related discussion:
text: SCTP could do that but we don't currently give such guarantees in the TAPS interface. About security: right... that's what I expected. TAPS isn't going to fall back to a less secure version of what you wish for... so I guess "mostly encrypted header" isn't a part of any API but as you say it's a meta-feature - it's implicit in the choice of QUIC, and when that's desired, falling back wouldn't happen, a TAPS system should always only give you QUIC. I think what's missing is a QUIC API that makes these wishes explicit...
Personally I'd say, for an HTTP application, that QUIC packet header protection is less of a concern. More that QUIC provides transport security on-par with TCP+TLS. Often an application can use the same TLS and crypto libraries for both. Fallback from QUIC to TCP can be a downgrade. But an application that does this can (and should) be aware of the security properties of the transport it is using. With HTTP, imagine a client that connects to URL and receives . This advertises the availability of QUIC and HTTP/3. If that transport connection fails for some reason, then there is not a viable fallback to TCP+TLS. This is an unlikely scenario but the specs allow for it to happen.
I would also have thought that encrypting data is more important - but surely having fall-back "under the hood" and just being aware of what you got (this can be queried in TAPS) is nicer than having to take care of it in the application. Fall-backs can get complex: e.g., when multi-homing, considering IPv6 ... a TAPS system can have a rich set to choose from and implement it all efficiently while shielding applications from this trouble - the application is still in control of things and can express limitations, as well as query what it got in case it did give the system some freedom. This HTTP case of preventing a fall-back... well, it is what it is :) No fall-back in this case, clearly.
I remain to be convinced that TAPS API will address the way that applications (I am familiar with) intend to use and interact with QUIC.
I think we're drifting towards a discussion of should a mapping document be written for TAPS to QUIC... which is a different topic.
Code change:
fall back to some other transport protocol.  In the case of HTTP, this fallback is TLS 1.3 over TCP. <ins> The IETF TAPS specifications I-D.ietf-taps-arch describe a system with a common API for multiple protocols and some of the implications of fallback between these different protocols, specifically precluding fallback to insecure protocols or to weaker versions of secure protocols. </ins> An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS 1.3 exposes control information to modification and manipulation in the network.  Further

Related discussion:
text: My observation was only that TAPS architecture is something the IETF is working upon, and it has documents that describe how to make an API that with functions and racing/fallback in a very different way to sockets. The guidance about what is an acceptable "alternative" connection appear common, at least enough to say there is a similarity and cite it.
The suggestion for a short informational reference seems good to me.
There is already PR
We merged PR . Is there anything we want to add or can this issue be closed?
The merged PR addresses all of my concerns. I'll let NAME be the judge whether his original issue has been addressed.
That looked good to me.
Thanks all!
o/ lgtm
Code change:
6.2. <del> In this solution, the server does not reduce the congestion window with the same amount when the "repaired packet" signal is received, i.e. when a packet has been lost but repaired.  Example of this solution could be based on RFC8511 or considering that recovering an isolated packet is not an actual sign of congestion. </del> <ins> [MICHAEL: this is even just a terrible idea.  There's no good rationale to back off less when a packet is repaired.]  In this solution, the server does not reduce the congestion window with the same amount when the "repaired packet" signal is received, i.e. when a packet has been lost but repaired.  Example of this solution could be based on RFC8511 or considering that recovering an isolated packet is not an actual sign of congestion. </ins> The advantage of the solution is that in cases where there is no actual congestion, coding could help in improving the transmission

Related discussion:
text: This proposes a complete re-vamp of the document. I would also suggest to completely remove sections 6 and 7, but rather than doing this yet, I inserted comments that explain why.
Le 17/01/2020 à 09:28, mwelzl a écrit : Yes ! Definitely agree.
Le 17/01/2020 à 13:50, francoismichel a écrit : OK for me.
Code change:
Integer <del> Default: :the TCP default </del> <ins> the TCP default </ins> This time value is advertised via the TCP User Timeout Option (UTO) RFC5482 at the remote endpoint to adapt its own "Timeout for aborting

Related discussion:
text: Following the discussion in , explain why TCP UTO is included as a Protocol-Specific Property, while other properties are not. Also, some minor consistency fixes.
Thanks for doing this!Thanks
Code change:
protect against passive attacker as active attackers can always get the Responder's identity by sending their own message_1.  EDHOC uses the Expand function (typically HKDF-Expand) as a binary additive <del> stream cipher.  HKDF-Expand is not often used as it is slow on long messages, and most applications require both IND-CCA confidentiality as well as integrity protection.  For the encryption of message_2, any speed difference is negligible, IND-CCA does not increase security, and integrity is provided by the inner MAC (and signature depending on method). </del> <ins> stream cipher which is proven secure as long as the expand function is a PRF.  HKDF-Expand is not often used as a stream cipher as it is slow on long messages, and most applications require both IND-CCA confidentiality as well as integrity protection.  For the encryption of message_2, any speed difference is negligible, IND-CCA does not increase security, and integrity is provided by the inner MAC (and signature depending on method). </ins> Requirements for how to securely generate, validate, and process the ephemeral public keys depend on the elliptic curve.  For X25519 and

Related discussion:
text: Reformulating security of expand as stream cipher instead of removing. HKDF-Expand is very often used.Added note of HKDF-Expand length restriction.Key use for different algorithms is already covered by COSE. Nothing is special with use inside of EDHOC. The text is clearly not correct at as signate can also be used in other methods.
Channeling from Erik. Use of the HKDF as EDHOC-KDF for generation of KEYSTREAM2 and encryption of message2 induces a max size. For example, HKDF-SHA256 has max output size 255*32 = 8160 bytes.
Code change:
(method equals 1 or 3), then mac_length_2 is the EDHOC MAC length of the selected cipher suite.  If the Responder authenticates with a signature key (method equals 0 or 2), then <del> mac_length_2 is equal to the output size of the EDHOC hash algorithm of the selected cipher suite. </del> <ins> mac_length_2 is equal to hash_length. </ins> ID_CRED_R - identifier to facilitate the retrieval of CRED_R, see

Related discussion:
text: 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.
Code change:
draft-04 <ins> Renumber the new handshake messages to be somewhat more consistent with existing convention and to remove a duplicate registration. </ins> Remove renegotiation. draft-03

Related discussion:
text: It has a proper definition in appendix A.4. Note though that RFC 4507 section 7 has allocated this value for the session_ticket/NewSessionTicket handshake type. This point may be moot if RFC 4507 has been integrated with TLS 1.3, in which case RFC 4507 should be added to the list of obsoleted RFCs.
The handshake packets in TLS 1.2 and earlier are numbered so that the HandshakeType for each of client and server is strictly increasing when packets arrive in correct order, and HandshakeType/10 indicates the flight number. This allows for using a simpler state-machine. The new handshake packets {server,client}keyshare break this convention by using numbers in the flight 2 range (17 & 18), while belonging in flight 1. This suggestion is to renumber them to eg clientkeyshare(5) and serverkeyshare(6)
Code change:
The key exchange and authentication modes this PSK is allowed to be used with <del> The Application-Layer Protocol Negotiation (ALPN) label(s) </del> <ins> The Application-Layer Protocol Negotiation (ALPN) protocol, if any is to be used </ins> The Server Name Indication (SNI), if any is to be used

Related discussion:
text: 1) Switches uses of ALPN label/value to "ALPN protocol" (to clarify this is referring to a single protocol, not the entire extension) 2) Remove plural from external PSK case (if there's not way for the client to select which protocol the 0-RTT data uses, it doesn't make sense for there to be multiple options) 3) Switch reference from RFC7443 to RFC7301 (I assume this is what was intended) I think this makes the intended behavior of the spec a bit more clear.
Code change:
9. <ins> Extensions to CONNECT-IP can define behavior changes to this mechanism.  Such extensions SHOULD define new capsule types to exchange configuration information if needed.  It is RECOMMENDED for extensions that modify addressing to specify that their extension capsules be sent before the ADDRESS_ASSIGN capsule and that they do not take effect until the ADDRESS_ASSIGN capsule is parsed.  This allows modifications to address assignement to operate atomically. Similarly, extensions that modify routing SHOULD behave similarly with regards to the ROUTE_ADVERTISEMENT capsule. 10. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies

Related discussion:
text: NAME let's discuss that on . I'd like to merge this PR first then decide on a plan for before submitting the next revision to the datatracker
Splitting {ADDRESSREQUESTROUTEADVERTISEMENT} into ...V4 and ..._V6 would result in smaller capsules that have fewer error conditions. It would also keep IPv4 and IPv6 logic distinct.
I don't think the size of these capsules matters given their rarity. I can see the error condition argument but it's pretty minor and would come at the cost of making the specification longer. I don't feel too strongly here, but I think I have a slight preference for keeping things as they are.
I agree with David that size is problem not a big concern. I think having one set of capsule is less complex.
I also have a preference for keeping the capsules as they are with versions included; it also allows the route advertisement capsule to include routes for both v4 and v6 in one capsule, which I think is very important. I wouldn't want to lose that feature.
I similarly have a preference for keeping v4 and v6 in one capsule and agree size is not a big concern.
I just chatted with NAME to see what error conditions he was thinking of. Upon discussion (v6 route advertised when only v4 address is available), we concluded that this is not an error case, it's just a route that's not yet usable. We've concluded that this is something that we're comfortable leaving as-is.
Implementing this on the client I was wondering if there should be a way for the client to ask for the server for an address without specifying what address it wants. This could allow a VPN client to mention that it wants an IPv6 address or not. If we think this could be useful, we could encode it as or .
I believe asking for the Any address is what we discussed previously, so +1
You mean ADDRESS_REQUEST(IPv4-0.0.0.0/32) don't you. I think the format of the request works fine. But we do need to before we implement this into the specification.
Yes — if we have this, one option is to always have an ADDRESS_REQUEST expected from clients, and then there doesn't need to be signaling. Or we do the simple solution to 54 to say "I expect to send N capsules with my request".
Code change:
9. <ins> Extensions to CONNECT-IP can define behavior changes to this mechanism.  Such extensions SHOULD define new capsule types to exchange configuration information if needed.  It is RECOMMENDED for extensions that modify addressing to specify that their extension capsules be sent before the ADDRESS_ASSIGN capsule and that they do not take effect until the ADDRESS_ASSIGN capsule is parsed.  This allows modifications to address assignement to operate atomically. Similarly, extensions that modify routing SHOULD behave similarly with regards to the ROUTE_ADVERTISEMENT capsule. 10. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies

Related discussion:
text: You're right this could be a potential solution to . Let's discuss them together tomorrow
Regarding IPv6, I think a standard request that would make sense is asking for any /64. I guess that works fine with this idea too?
Oh that's interesting, if the IP Address is or , the prefix length is a hint for the requested length. I like that.
IETF 114: Add an editorial sentence to "remember, what you ask for may not be what you get, especially with regards to address families". A request should be paired with a response, multiple requests can just say "you have the same ones you had before". Clarify that it's cumulative. Also solves unassign/removal of addresses.
So there appear to exist some downside with the timing of the interactions when one want to use Address-Request capsule. So the basic problem is simply that the proxy will assign an address prior to the Address-Request capsule has been received, thus preventing the proxy from processing the request in the right context. So lets assume that the client has already created one connect-IP request with a limited scope and been assigned IP-A. Then it want to make an additional request for another limited scope proxying and would like to get the same address assigned. Due to the separation between the HTTP request for the Connect-IP and the capsule Address-Request a server can actually process the whole HTTP request prior to receiving the Address-Request. Resulting potentially in that another IP address assignment (IP-B) be provided to the client, despite it asking for IP-A to be assigned also to the request. So does the HTTP request needs an indicator parameter to tell the proxy to wait for one or more "request" capsules from the client before processing the request?
Out of curiosity, in what scenario would the client "like to get the same address assigned"? It makes sense for the proxy to decide to reuse addresses to save its address pool when the scoping allows it, but why would the client care?
I could imagine this happening if the client was trying to resume some previous session that it lost due to an outage? Seems to be niche, but it's certainly possible.
So the most obvious use case for this is to request iproto= CMP in combination with for example UDP.