Question: protocol negotiation.  TLS uses Application Layer Protocol Negotiation (ALPN) ALPN to select an application protocol.  Unless another mechanism is used for agreeing on an application protocol, <del> endpoints MUST use ALPN for this purpose.  When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 in QUIC- TRANSPORT) if an application protocol is not negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see tls- errors).  While ALPN only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN negotiation fails. </del> <ins> endpoints MUST use ALPN for this purpose. When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 of QUIC-TRANSPORT) with a no_application_protocol TLS alert (QUIC error code 0x178; see tls-errors) if an application protocol is not negotiated.  While ALPN only specifies that servers use this alert, QUIC clients MUST use error 0x178 to terminate a connection when ALPN negotiation fails. </ins> An application protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible

Would it still be the best approach to define the same anti-forgery limit across all cipher suites, even if this means going down to ? Of course, I'm happy to discuss more with NAME !
Thanks for checking this NAME I was a little concerned about the PRP/PRF split, so I'm glad to have you correct me. I ultimately went with per-AEAD recommendations, and a lower limit for CCM. That's mainly to establish some sort of uniformity around 2^-60 and 2^-57. Even if those are basically arbitrary choices, at least they are defensible (I think!) and using them uniformly establishes the right expectations about what the standard is. I'm comfortable with specifying different limits for each AEAD in specifications. In practice, however, I expect that a far lower tolerance for forgery attempts. Assuming that these numbers work out, a review of the pull request would be greatly appreciated. If there are other relevant papers, I'm always happy to pull those in as well.
I realize that I didn't respond to NAME That advice applies to the limits that TLS specifies already; this issue is primarily about responding to forgeries. That said, 1G is pretty good advice. However what we've seen from this analysis that 1G results in a lower safety margin than TLS aims for. But it's close enough that if the AEAD is as good as the set we have here, you are probably OK. However, this does depend a lot on the specific AEAD. I'd be uncomfortable using so simple a guide in the general case.
NAME points out an error in my calculation. I had based my calculations on direct mapping of in the CCM analysis to in our calculations. That is, was the number of blocks in the message. But the analysis by Jonsson defines this as: ! The definition of Beta is the CCM function, so this function really reduces to 2 times the length of the message (in blocks), plus 1 (to account for the additional encryption). We can ignore the extra 1 as that is absorbed by the tag length. I'm updating the numbers in the PR. The result is another halving of the number of packets. NAME NAME it's pretty clear that I'm out of my depth here, so your input would be highly valued.


Question: protocol negotiation.  TLS uses Application Layer Protocol Negotiation (ALPN) ALPN to select an application protocol.  Unless another mechanism is used for agreeing on an application protocol, <del> endpoints MUST use ALPN for this purpose.  When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 in QUIC- TRANSPORT) if an application protocol is not negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see tls- errors).  While ALPN only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN negotiation fails. </del> <ins> endpoints MUST use ALPN for this purpose. When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 of QUIC-TRANSPORT) with a no_application_protocol TLS alert (QUIC error code 0x178; see tls-errors) if an application protocol is not negotiated.  While ALPN only specifies that servers use this alert, QUIC clients MUST use error 0x178 to terminate a connection when ALPN negotiation fails. </ins> An application protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible

Good catch, yes, the double passing over the message requires a factor 2 here. (The AD a may also be up to 3 blocks if I understand the header format correctly, but I guess that's negligible compared to the conservative 2^10 message size.)
Good point about the AD. The AD - at least for QUIC - is always sent, so that fits in the same space. We don't necessarily need to double count the tiny number of blocks, but as you say, counting that only once yields a negligible difference. If we had a large AD that wasn't also transmitted, that would be different.
Agreed. To be precise: if I'm not mistaken the AD isn't counted at all right now ( accounts for the max. payload blocks), but of course the difference is still negligible as long as the AD is small.
Thanks for the edits!


Question: Some audio codecs, notably Opus RFC6716 and AMR RFC4867, support their own in-band FEC mechanism, where redundant data is included in <del> the codec payload. </del> <ins> the codec payload.  This is similar to the redundant encoding mechanism described above, but as it adds no additional framing, it can be slightly more efficient. </ins> <del> For Opus, packets deemed as important are re-encoded at a lower bitrate and added to the subsequent packet, allowing partial recovery </del> <ins> For Opus, audio frames deemed important are re-encoded at a lower bitrate and appended to the next payload, allowing partial recovery </ins> of a lost packet.  This scheme is fairly efficient; experiments performed indicate that when Opus FEC is used, the overhead imposed <del> is about 20-30%, depending on the amount of protection needed.  Note that this mechanism can only carry redundancy information for the immediately preceding packet; as such the decoder cannot fully recover multiple consecutive lost packets, which can be a problem on wireless networks.  See RFC6716, Section 2.1.7 for complete details. </del> <ins> is only about 20-30%, depending on the amount of protection needed. Note that this mechanism can only carry redundancy information for the immediately preceding audio frame; as such the decoder cannot fully recover multiple consecutive lost packets, which can be a problem on wireless networks.  See RFC6716, Section 2.1.7 for complete details. </ins> For AMR/AMR-WB, packets can contain copies or lower-quality encodings <del> of multiple prior audio frames.  This mechanism is similar to the redundant encoding mechanism described above, but as it adds no additional framing, it can be slightly more efficient.  See RFC4867, Section 3.7.1 for details on this mechanism. </del> <ins> of multiple prior audio frames.  See RFC4867, Section 3.7.1 for details on this mechanism. </ins> In-band FEC mechanisms cannot recover any of the RTP header.

It's similar to the redundant encoding, but done within the Opus bitstream, rather than at the RTP level.


Question: This 8-byte field contains arbitrary data. <del> A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is sufficient to ensure that it is easier to receive the packet than it is to guess the value correctly. </del> <ins> Including 64 bits of entropy in a PATH_CHALLENGE frame ensures that it is easier to receive the packet than it is to guess the value correctly. </ins> The recipient of this frame MUST generate a PATH_RESPONSE frame (frame-path-response) containing the same Data.

I see a couple of places where we require that values have high entropy. For instance of the packet header. The remainder of the first byte and an arbitrary number of bytes following it that are set to unpredictable values. The last 16 bytes of the datagram contain a Stateless Reset Token. and to ensure that it is easier to receive the packet than it is to guess the value correctly. In general, this means that things contain sufficient entropy (so, for instance, you might have a value with some fixed values and some high entropy values). In any case, I think the first of these should be "indistinguishable from random" and the second should be "containing at least 64 bits worth of entropy"
LGTM


Question: 6. In this design, a client wishes to make a request of a server that is <del> authoritative for the Target Resource.  The client wishes to make this request without linking that request with either: </del> <ins> authoritative for a Target Resource.  The client wishes to make this request without linking that request with either: </ins> The identity at the network and transport layer of the client (that is, the client IP address and TCP or UDP port number the

Most of the text was correct in that we talk about making a request of a resource. Where the text refers to making requests of a server, those usages seem to be correct.
Section 5 details HTTP usage. It seems it's technically correct but the section closes with a sequence of paragraphs that jump back and forth between statements about how an Oblivious Gateway Resource treats requests or responses. Perhaps these could be consolidated to present requests first consistently. I.e. swap the final two paragraphs around
mnot recently made a PR (now merged) that replaced "requests of a server" with "requests to an origin server" and that feels both grammatically and technically more correct. However, there are still few cases peppered through the doc that use "requests of a server". I'd kindly ask the editors to revisit these and consider if they could be made more consistent with the above


Question: The payload of an Initial packet includes a CRYPTO frame (or frames) containing a cryptographic handshake message, ACK frames, or both. <del> PING, PADDING, and CONNECTION_CLOSE frames are also permitted.  An endpoint that receives an Initial packet containing other frames can either discard the packet as spurious or treat it as a connection error. </del> <ins> PING, PADDING, and CONNECTION_CLOSE frames of type 0x1c are also permitted.  An endpoint that receives an Initial packet containing other frames can either discard the packet as spurious or treat it as a connection error. </ins> The first packet sent by a client always includes a CRYPTO frame that contains the start or all of the first cryptographic handshake

When we prohibited the use of application-layer CONNECTION_CLOSE in these packets, we should have updated the text in the description of the packets also.
I think the spec is ambiguous when it says in section 17.2: and: >Handshake packets MAY contain CONNECTIONCLOSE frames. But CONNECTIONCLOSE can mean 0x1c or 0x1d. Are both permitted during the handshake?
NAME In this case, the intent is to allow both. Unless explicitly specified, I would read the text to mean both types of CONNECTION_CLOSE frames.
Okay, if more people think that way, we can close with no action.
So on the surface, there is no inconsistency: the two sections permit CONNECTIONCLOSE. But the question about the different types of CONNECTIONCLOSE is more relevant than NAME response might imply. We currently require that CONNECTIONCLOSE of type 0x1d (application close) is not sent in Initial or Handshake packets. So that's a drafting error, and we might reasonably take this as an editorial issue. However, if the question is about what a reaction to receiving an application CONNECTIONCLOSE in one of those packets, we might consider a different posture. If you get an application CONNECTIONCLOSE in an Initial packet that is otherwise valid, you probably want to drop the connection. And you probably don't want to start sending CONNECTIONCLOSE in response every time, because that leads to madness. But this is a general problem: if you detect and error and that error keeps being repeated, it probably isn't a good idea to generate a CONNECTION_CLOSE in response to every infraction.
(removing my comment as NAME posted what needs to be said couple of seconds earlier).
I'm going to re-close the can of worms I half-opened in my earlier comment and take this as editorial. From memory, the larger question of how to deal with junk is something we've discussed several times. If anyone wants to take that up, I'm happy to do that, but let's at least correct the obvious error.
It does make sense that we only allow 0x1c during the handshake.
NAME : Apologies, I misspoke -- I was speaking to interpretation of text, rather than the actual question itself.


Question: The sending endpoint SHALL write the Code of the original CoAP message into the plaintext of the COSE object (see plaintext).  After that, the sending endpoint writes an Outer Code to the OSCORE <del> message.  With one exeception (see observe-option-processing) the Outer Code SHALL by default be set to 0.02 (POST) for requests and to 2.04 (Changed) for responses.  The receiving endpoint SHALL discard the Outer Code in the OSCORE message and write the Code of the COSE object plaintext (plaintext) into the decrypted CoAP message. </del> <ins> message.  With one exeception (see observe) the Outer Code SHALL by default be set to 0.02 (POST) for requests and to 2.04 (Changed) for responses.  The receiving endpoint SHALL discard the Outer Code in the OSCORE message and write the Code of the COSE object plaintext (plaintext) into the decrypted CoAP message. </ins> The other currently defined CoAP Header fields are Unprotected (Class U).  The sending endpoint SHALL write all other header fields of the

Back to one processing description Observe is now primarily inner Simplified processing Explicit cancellation by intermediary not supported


Question: For application messages, a chain of keys is derived for each sender in a similar fashion.  This allows forward secrecy at the level of application messages within and out of an epoch.  A step in this <del> chain (the second subscript) is called a "generation". As before the value [sender] represents the index of the member that will use this key to send, encoded as a uint32. [[ OPEN ISSUE: The HKDF context field is left empty for now.  A proper security study is needed to make sure that we do not need more information in the context to achieve the security goals.]] [[ OPEN ISSUE: At the moment there is no contributivity of Application secrets chained from the initial one to the next generation of Epoch secret.  While this seems safe because cryptographic operations using the application secrets can't affect the group init_secret, it remains to be proven correct. ]] The following rules apply to the usage of the secrets, keys, and nonces derived above: Senders MUST only use a given secret once and monotonically increment the generation of their secret.  This is important to provide Forward Secrecy at the level of Application messages.  An attacker getting hold of a member specific Application Secret at generation [N+1] will not be able to derive the member's Application Secret [N] nor the associated AEAD key and nonce. Receivers MUST delete an Application Secret once it has been used to derive the corresponding AEAD key and nonce as well as the next Application Secret.  Receivers MAY keep the AEAD key and nonce around for some reasonable period. Receivers MUST delete AEAD keys and nonces once they have been used to successfully decrypt a message. </del> <ins> chain (the second subscript) is called a "generation".  The details of application key derivation are described in the astree section below. </ins> 7.

Update change log for draft-07 No conflicting PRs so I did break many lines that were too long. Fix a few minor editorial issues after merging the tree-based application key schedule.


Question: [1] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115 <del> [2] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/117 [3] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/116 </del> <ins> [2] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/116 </ins>

Expands the definition of the resource set registration protocol, used by an RS to declare a resource set to an AS at runtime and receive a reference identifier for that resource set to hand to a client.
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: f9aac0b2af163c0f9a58ba17e93db7e8956140bf :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Registering a Resource Handle: Editor's note: It's not an exact match here because the "resource_handle" returned now represents a collection of objects instead of a single one. Perhaps we should let this return a list of strings instead? Or use a different syntax than the resource request? Also, this borrows heavily from UMA 2's "distributed authorization" model and, like UMA, might be better suited to an extension than the core protocol


Question: A Flags Extension for TLS 1.3 <del> draft-ietf-tls-tlsflags-09 </del> <ins> draft-ietf-tls-tlsflags-10 </ins> Abstract

This proposed text disallows specifying a flag extension where the response is a regular extension with content rather than a mere acknowledgment.
Well, I think of this as being the request extension. I can live with this if it's the WG consensus, but it seems like it would be useful to be able to say "I support largeish extension X" (we already have some such extensions) and it would be kind of sad if that took 4 bytes.
Seems strange to have to state this, but that's OK. Do you want to explain why? That is, because this results in a "response" extension appearing without a "request" extension, which is not permitted.


Question: scenarios, endpoints MUST follow the recommendations from BCP38 to prevent source address spoofing. <del> 10. </del> <ins> 11. </ins> <del> 10.1. </del> <ins> 11.1. </ins> This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <del> 10.2. </del> <ins> 11.2. </ins> This document will request IANA to update the entry for the "masque" URI suffix in the "Well-Known URIs" registry maintained at

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".


Question: scenarios, endpoints MUST follow the recommendations from BCP38 to prevent source address spoofing. <del> 10. </del> <ins> 11. </ins> <del> 10.1. </del> <ins> 11.1. </ins> This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <del> 10.2. </del> <ins> 11.2. </ins> This document will request IANA to update the entry for the "masque" URI suffix in the "Well-Known URIs" registry maintained at

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.


Question: scenarios, endpoints MUST follow the recommendations from BCP38 to prevent source address spoofing. <del> 10. </del> <ins> 11. </ins> <del> 10.1. </del> <ins> 11.1. </ins> This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <del> 10.2. </del> <ins> 11.2. </ins> This document will request IANA to update the entry for the "masque" URI suffix in the "Well-Known URIs" registry maintained at

Then getting ICMP for another IP address then the one you already have UDP for is mostly useless if you intended to use the ICMP messages for hints when things fails for you UDP based protocol. I would note that for an endpoint liking to do P2P NAT traversal stuff getting an IP address rather than using Connect-UDP does make sense as it ensure the client has control. It enables the IP address for its UDP traffic to be Endpoint-Independent Mapping (RFC4787). This might be niche usages but I would like to avoid creating artificial barriers that makes things impossible or at least hard to realise.
Thanks, this makes sense. Should we suggest that clients bundle the ADDRESS_REQUEST in the same packet as the HTTP headers and suggest that servers check for those before responding?
I am still worried that this creates issues as your request may not fit in a single packet to begin with. My solution would be to actually move the address request part into the HTTP request itself as header field. That would ensure an atomic operation and no risk for errors.
Magnus, is your proposal to require, or to allow as an option, for the address request to be moved into the HTTP request? Why not bundle the capsules over a reliable delivery mechanism instead?
I first of all want to ensure that you can do a request that ensures that for those cases when it is necessary to interpret the Connect-IP request in the context of desired IP address it can done. Without uncertainties or requiring to have wait time to see if there are capsules incoming. So I think primarily allow as an option. I think a question back to your usages, do you have cases where one would need additional capsules to correctly interpret the option. Should we look for an other solution than the one I proposed to better cover the necessary functionality?
I want to be able to continue to do ADDRESS_ASSIGN capsules during the lifetime of the connection to support e.g., IPv6 Privacy extensions but without having to delegate the entire subnet. So I don't want to move to header-only.
I think NAME is describing something similar to the / capsules that we had in the original Google . The only difference is that we would add an HTTP header to say "start off in atomic mode and wait for atomic end before sending addresses and such". While I think this does sound useful, does it need to be in the core spec or could it be an extension?


Question: scenarios, endpoints MUST follow the recommendations from BCP38 to prevent source address spoofing. <del> 10. </del> <ins> 11. </ins> <del> 10.1. </del> <ins> 11.1. </ins> This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <del> 10.2. </del> <ins> 11.2. </ins> This document will request IANA to update the entry for the "masque" URI suffix in the "Well-Known URIs" registry maintained at

Is there any reason to not bring back the capsules?
The only reason I can think of is to keep the core spec as short and simple as possible. But if we think this is an important feature then I'm not opposed to bringing back .
I agree with the sentiment of keeping the core spec short and simple, but the trade-off is also knowing what the minimum viable featureset we can always rely on is. If we conclude that capsules are in that set, that IMHO weighs towards including them. Given that both Magnus and I have now presented use-cases for atomicity, I think this finally swings towards including?
I agree with that
So why I used atomic here, was due to the split between HTTP and Capsules. So I don't see this issue currently motivates the need for ATOMIC capsules. I really would prefer that the necessary parameters for the CONNECT-IP request are in the HTTP request, either in the URI or in an HTTP field. To be clear, I understand the need for the capsules as they are useful for doing things after the initial request, but creating this binding between the HTTP request and the capsules are creating its sets of complexities. Likely bigger than duplicating the carrying of the necessary information results in, especially when they may be use cases related.
I agree I with Magnus and think we should specify a ay to add the address request to the http request. If there is a timing dependency it's better to put all needed information into the same request than specifying extra and complex logic to achieve the same in hindsight. That doesn't mean that we don't need the address request capsule (for later use in the connection). I think we need both.
I dislike having two ways of conveying the same thing. How about a simple HTTP header that tells the receiver that there are 4 capsules coming right after the HTTP headers?
I'd prefer to avoid "atomic capsule" starts and ends. If we need a way to guarantee inclusion of the local address in the first request, having it be in the HTTP request makes sense, either as another URI parameter, a header to say what address you want, or a header to say you will have capsules that need to be parsed before responding. That latter option is flexible, certainly, but could be over-engineered. Another option is to tightly scope a header to the use case we think is relevant.


Question: scenarios, endpoints MUST follow the recommendations from BCP38 to prevent source address spoofing. <del> 10. </del> <ins> 11. </ins> <del> 10.1. </del> <ins> 11.1. </ins> This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <del> 10.2. </del> <ins> 11.2. </ins> This document will request IANA to update the entry for the "masque" URI suffix in the "Well-Known URIs" registry maintained at

If the use case is "please use the same address as this other request stream I already have for connect-ip or connect-UDP", we could just have a header to say for any connect- request that it is entangled with another and should share some properties. I could imagine this even without CONNECT-IP. Today with private relay, we have to ask the proxies to prefer to use the same local IP for everything in a connection from the client, but letting the client choose what gets grouped might be even nicer. This option also lets you issue multiple requests, say they should share, without needing to know exactly which IP any of them will get assigned first.
Unfortunately requests and headers are end-to-end but streams are hop-by-hop so there is no easy HTTP way to have a request refer to another request. I'd be supportive of adding the header but I'd push back on adding a header that duplicates a capsule. This is starting to feel like something best-served by an extension
You could solve the correlation by having a "group" ID that you attach to all related requests. No need to refer by stream ID.
What is the scope of a group ID? Connection? If so it's the same as stream IDs.
I think this should be some extension, but it could be a UUID too, doesn't need to be connection specific.
Ah, thanks. Yeah UUID would work. Back to the issue at hand, I propose this feature request get moved to an extension.
All of these alternatives strike me as much more complex that the semantics of . I'd rather we have a single mechanism even if it's slightly more powerful and restrain it's use than try to invent new ways to solve each problem that arises.
Atomic doesn't help coordinate between requests on different streams, etc, so it's not really solving the full problem here. Either way, I think this is something to defer to an extension.
Headers don't solve that problem either, so I'm not sure that argument really makes sense in this context. Cross stream coordination seems out of scope to me.
So you are taking this into directions I did not intended. I am just asking for how to ensure that the server does not answers the client's request prior to having received any capsules if they are coming.


Question: scenarios, endpoints MUST follow the recommendations from BCP38 to prevent source address spoofing. <del> 10. </del> <ins> 11. </ins> <del> 10.1. </del> <ins> 11.1. </ins> This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <del> 10.2. </del> <ins> 11.2. </ins> This document will request IANA to update the entry for the "masque" URI suffix in the "Well-Known URIs" registry maintained at

And the real issue is that the server can't know unless the client either includes the corresponding data in the HTTP request or includes an indication that there will be capsules that are relevant to the requests. So, my main worry is if waiting for capsule to answer will actually work if there are an HTTP 1.x intermediary connection on the path between the client and the server. I guess its is sending the capsule after the request and hope it makes it. Because to my understanding in HTTP datagram the peer does not expect any data to arrive so it must be upgraded. Thus, one can end up in cases where the capsule protocol does not make it, where the HTTP request does arrive.
While we might want to have a more generic extension to relate information to multiple requests, I think the problem Magnus describes needs a solution now. The problem is that there is a dependency between replying/react to a connect request and potentially information send in capsules. The best solution is to send this information together with the connection request instead. I don't see any concern to have a http request or URI parameter and the capsule. What's the problem about that?
Magnus, what is "the client's request" here? Is it the extended-connect itself, or a response to a capsule? If it's the former, the server can't know what capsules, if any, are coming at this time, as we haven't yet established we are using the capsule protocol. If it's the latter, capsules trivially solve this, as you cannot process any of the requests until the capsule is received. Mirja, I'd like to avoid having 2 ways to do things, especially since putting it on the HTTP request is a less-generic mechanism and cannot be reused during the connection, whereas capsules can. If we believe this feature is important, I'd like us to solve it generically, rather than special-casing one use case we are aware of right now.
So the client's request is the HTTP request that is only complete in semantics when combined with the request-address capsule.
Sorry Magnus, I'm not sure I understand what you're trying to say. I don't think we can enforce a semantic that a higher-level HTTP request is only complete after some bytes on the then-negotiated protocol have been exchanged.


Question: scenarios, endpoints MUST follow the recommendations from BCP38 to prevent source address spoofing. <del> 10. </del> <ins> 11. </ins> <del> 10.1. </del> <ins> 11.1. </ins> This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <del> 10.2. </del> <ins> 11.2. </ins> This document will request IANA to update the entry for the "masque" URI suffix in the "Well-Known URIs" registry maintained at

But this is really the issue, there is currently no way for a client to ask the server to only provide a targeted connect-IP forwarding if the IP address it can provide is the one the client asks for in a consistent way. My interpretation of the specification is that either; 1) the server will never take the request-addr into account initially for the request, and interpret the request-addr after it has created a Connect-IP forwarding 2) the server will sometime take the request-addr into account by have a short delay awaiting for the request-addr capsule, which may or may not make it in time for the implementation specific timer. This non-consistency or failure to address a use case that I think several was interested in resolving is a real problem. A problem I think we will have to take with us to the meeting.
This ultimately stems from us not having an explicit capsule/message to indicate that forwarding should actually begin. Right now it's implicit as soon as the capsule is assembled with the IP addressing information. This is leading to your proposal to stick more things onto the initial request, whereas I believe the correct solution is to add more capabilities to the capsule protocol to express these scenarios.
I will consider what you are saying. However, I will note that we might have different goals. I do have a need for identifiable streams that can be referred to in extension signalling. Using capsules does not achieve that with the current design as the stream identifier comes from the HTTP request, not the subsequent capsule signalling.
I hope so, constructive discussion relies on all of us considering what the others are saying Given that we're all trying to solve slightly different problems here, I see two outcomes: we have one simple generic solution that happens to work for everyone we punt this to more specific extensions since these problems are not generic
So I think the issue here is what we consider core functionality. My observation here is that Alex is promoting functionality that will make it easy to make quite rich things for the network tunnelling use case that you are promoting. While I am bringing up something that to me appear core for the single endpoint tunnelling. So I think we actually need to understand the issues as well as what usage and how usable this is in common and how to handle where the different use cases actually benefits from having the functionality in different places.


Question: scenarios, endpoints MUST follow the recommendations from BCP38 to prevent source address spoofing. <del> 10. </del> <ins> 11. </ins> <del> 10.1. </del> <ins> 11.1. </ins> This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <del> 10.2. </del> <ins> 11.2. </ins> This document will request IANA to update the entry for the "masque" URI suffix in the "Well-Known URIs" registry maintained at

I'll reiterate my suggestion from the meeting: it would be better to have IP-version-specific capsule types for each capsule. It saves a byte and also avoids problems with version mismatches.Thanks! I left 2 minor editorial questions, but feel free to merge as-is.


Question: single canonical representation outweighs the convenience of easy human representations or loss of precision in a conversion. <del> Use of SI prefixes such as "k" before the unit is not allowed. </del> <ins> Use of SI prefixes such as "k" before the unit is not recommended. </ins> Instead one can represent the value using scientific notation such <del> a 1.2e3.  TODO - Open Issue.  Some people would like to have SI prefixes to improve human readability. </del> <ins> a 1.2e3.  The "kg" unit is exception to this rule since it is an SI base unit; the "g" unit is provided for legacy compatibility. </ins> For a given type of measurement, there will only be one unit type defined.  So for length, meters are defined and other lengths such

This should now consider and . There are no perfect solutions for these, but the solutions chosen should be close.
I don't agree wth some of this but agree with a bunch. I took carsten's changes for all the parts I agree with and put them in URL
I might suggest we pull that PR and then look at what is left (on a bunch of them it is simply if there should be an * suggesting don't use or not) then we can rebase this PR and see what is left to resolve.
Oops, I just changed my PR to react to your comments before seeing
Pushed another version that has both / and % for the same thing, where % is marked with a *
Now, instead of delete, it's "not recommend" and mentions kg as exception. I think this is good to merge.
The following units are questionable: % -- this looks like a percentage (0..100), but it is not (0..1). count -- what? This is about a dimensionless quantity? %RH, %EL appear to be percentages, but imply a quantity. EL may be a quantity, but the unit is second. In SI, we don't do new units for new quantities (there is no "millimeter radius" or "nanometer wavelength"). Bspl -- this really should be in dB (see ), SPL is the quantity again. beat/min, beats -- these should be 1/min (but see ) and 1 (dimensionless); how is beats different from count? We don't have bit (but bit/s), byte. 1/min is there only for heartbeats, not for revolutions ("rpm"). Should really be 1/s (but see ). lat and lon are a bit weird, too. (Celsius is also questionable -- the rationale of should call for all measurements being expressed in Kelvin.)
on on kevin vs C, every thermostat manufacture I can find has said they want C over kelvin. bunch of implementation are using 0 to 1 for light levels but imagine we could change % to 0 to 100 count - yep count :-) Bunch of sensors simply count pulses of who knows what. Totally agree this is not a unit but this is the pragmatic sort of thing needed EL is a great example of something that many sensors in sports have to deal with in common way.


Question: single canonical representation outweighs the convenience of easy human representations or loss of precision in a conversion. <del> Use of SI prefixes such as "k" before the unit is not allowed. </del> <ins> Use of SI prefixes such as "k" before the unit is not recommended. </ins> Instead one can represent the value using scientific notation such <del> a 1.2e3.  TODO - Open Issue.  Some people would like to have SI prefixes to improve human readability. </del> <ins> a 1.2e3.  The "kg" unit is exception to this rule since it is an SI base unit; the "g" unit is provided for legacy compatibility. </ins> For a given type of measurement, there will only be one unit type defined.  So for length, meters are defined and other lengths such

They use this and it works well for them
So I changed % to mean percentage. Cel of course stays in (even though it is wrong wrong wrong :-). I have marked count and EL with the "not so recommended for new producers" range. But we don't really have a base unit for "1" (dimensionless) either. The problem remains that giving a unit doesn't tell you what quantity actually has been measured, and the trend to make more and more finer grained units for the same kinds quantities measured in different ways (as in psi vs. psig etc.) leads into the woods.
just finding all the email now … I think the thing that people like about this is it’s not a SI unit, it’s something that tells you something useful about what you are measuring across a wide range of devices. I think we need to think of these from a point of view of broadly useful than are they a SI unit. Agree with your slippery slope psi, psig, etc argument but all of those exist for a reason.
The SI unit for mass is kg. says: That leads to being unable to use the SI unit for mass, instead, we are using g. But then we are using derived units such as l (dm3) and l/s (dm3/s). So: We need to decide the above TODO. We need to decide whether to stick with SI units or allow simple names for derived units (gram, minute, liter). Domain-specific units are often weird (1/min = "rpm", mmHg or mol/dl in medicine, ...).
I think a key part of the registry vs existing SI unit tables was to be able to use things that were not proper units but agree things can be cleaned up. Clearly rpm and bpm have the same unit in the sense of what the dimensions are but what they are used to measure are pretty different and knowing that it is bpm often provides a level of information about how to process the information. As related to our whole conversation on why we needed the IANA table, the ability to have things in this that are not really a classic SI unit is the key value of SenML. The rules are just guidelines. If we want to change the unit of mass from g to kg, we can do that but the point on the prefixes was not to have both g and kg as that just reduces interoperability


Question: Support for a SSRC-multiplexed flexfec stream to protect a given RTP stream SHOULD be indicated by including one of the formats described <del> in I-D.ietf-payload-flexible-fec-scheme, Section 5.1, as an </del> <ins> in I-D.ietf-payload-flexible-fec-scheme, Section 5.1.2, as an </ins> additional supported media type for the associated m= section in the SDP offer RFC3264.  As mentioned above, when BUNDLE is used, only a single flexfec repair stream will be created for each BUNDLE group,

It's similar to the redundant encoding, but done within the Opus bitstream, rather than at the RTP level.


Question: KT log under a user's identity.  The verification function would correspond to verifying a key's inclusion in the log for a claimed identity, together with the KT log's mechanisms for a user to <del> monitor and control which keys are associated to their identity. </del> <ins> monitor and control which keys are associated with their identity. </ins> By the nature of its roles in MLS authentication, the AS is invested with a large amount of trust and the compromise of one of its

For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.


Question: header extension defined in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 11. <ins> An "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP6 ::", because no candidates have yet been gathered. </ins> An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. An "a=sendrecv" line, as specified in RFC3264, Section 5.1.

lgtm
I think the dummy candidates should be v4 not v6 as many things just don't do v6 but other than that looks reasonable. You don't really need to specify the address at all the the lines when you don't know the port can just look like a=rtcp:9 With no IP address or family
NAME The IP6 vs IP4 is described in URL, so this isn't a JSEP thing. Given that this is part of the trickle spec, and only trickle endpoints will get these candidates, I don't see any problem. As to whether a=rtcp can just have the port, consider the case where RTP candidates have been gathered, but no RTCP candidates have yet been gathered. In that case, we certainly need to have the full a=rtcp:9 IP6 ::, so I think it makes sense to include it in all cases where RTCP candidates have not yet been gathered.
I don't care much about this so fine if not change is made. I agree it is a trickle-ice draft issue. However, when I read that, it seems that it would be fine with "a=rtcp:9" with no address. It seems the reason we used 9 was to provide something that stuff that did not implement trickle ICE would not barf on. I have no tested but an address of "IP6 ::" seems like something that has high odds of stuff barfing on. Anyways, no big deal with me one way or the other. On Sep 12, 2014, at 7:49 PM, Justin Uberti EMAIL wrote:
Only trickle endpoints will even receive an offer with these dummy addresses and ports, so compatibility with old non-trickle stuff is not an issue. LMK if you have any further concerns, otherwise I will merge later today.
I concur that we should merge this. , Justin Uberti EMAIL wrote:
On Sep 18, 2014, at 9:34 AM, Justin Uberti EMAIL wrote: ah - my bad - makes sense Merge it !


Question: If an authenticator request is present, the extensions used to guide the construction of these messages are taken from the authenticator <del> request.  If the certificate_request_context from the authenticator request has already been used in the connection, then no authenticator should be constructed.  If there is no authenticator request, the extensions are chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request. In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </del> <ins> request.  Unrecognized extensions MUST be ignored.  If the certificate_request_context from the authenticator request has already been used in the connection, then no authenticator should be constructed.  If there is no authenticator request, the extensions are chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request.  In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </ins> 4.2.1.

In Section 3 of the RFC, it states that the authenticator request includes those extensions allowed for the CertificateRequest message. However, this does not mean it could only includes them and other extensions could also be sent. In the TLS spec CertificateRequest explicitly states "Clients MUST ignore unrecognized extensions.", we should have the same here.


Question: Servers SHOULD authenticate using certificates with at least a 2048-bit modulus for the public key. <del> In addition, the use of the SHA-256 hash algorithm is RECOMMENDED, SHA-1 or MD5 MUST NOT be used (see CAB-Baseline for more details). Clients MUST indicate to servers that they request SHA-256, by using the "Signature Algorithms" extension defined in TLS 1.2. </del> <ins> In addition, the use of the SHA-256 hash algorithm is RECOMMENDED; and SHA-1 or MD5 MUST NOT be used (see CAB-Baseline for more details).  Clients MUST indicate to servers that they request SHA- 256, by using the "Signature Algorithms" extension defined in TLS 1.2. </ins> 8.

Addressing Roman's AD comments.
has 2 conflicts, not sure how to resolve, the updates look fine. Please merge.
There was a conflict with the 8174 reference being in the other branch. I added it in because it's now part of the terminology paragraph.
Please address the following IDNits: -- The document seems to lack an IANA Considerations section. (See Section 2.2 of URL for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7525, but the abstract doesn't seem to mention this, which it should. Section 1. Editorial. -- s/RFC 5246 [RFC5246]/[RFC5246]/ -- s/RFC 6151 [RFC6151]/[RFC6151]/ -- s/RFC7525 [RFC7525]/[RFC7525]/ Section 1. Editorial. For symmetry with the rest of the text: OLD RFC 6151 [RFC6151] details the security considerations, including collision attacks for MD5, published in 2011. NEW In 2011, [RFC6151] detailed the security considerations, including collision attacks for MD5. Section 1. Please provide a reference for "Wang, et al". Is there a reference to provide for the "the potential for brute-force attack" Section 6. Editorial Nit. s/RFC5246 [RFC5246]/[RFC5246]/ Section 6. Move the text "In Section 7.4.1.4.1: the text should be revised from" out of the "OLD" block of text to be its own intro paragraph so that the OLD vs. NEW is a clear cut-and-paste. Section 7. Editorial. s/ RFC7525 [RFC7525]/[RFC7525]/ Section 7. SHA-1 is also not mentioned in RFC7525. Recommend: OLD The prior text did not explicitly include MD5 and this text adds it to ensure it is understood as having been deprecated.


Question: Servers SHOULD authenticate using certificates with at least a 2048-bit modulus for the public key. <del> In addition, the use of the SHA-256 hash algorithm is RECOMMENDED, SHA-1 or MD5 MUST NOT be used (see CAB-Baseline for more details). Clients MUST indicate to servers that they request SHA-256, by using the "Signature Algorithms" extension defined in TLS 1.2. </del> <ins> In addition, the use of the SHA-256 hash algorithm is RECOMMENDED; and SHA-1 or MD5 MUST NOT be used (see CAB-Baseline for more details).  Clients MUST indicate to servers that they request SHA- 256, by using the "Signature Algorithms" extension defined in TLS 1.2. </ins> 8.

NEW The prior text did not explicitly include MD5 or SHA-1; and this text adds guidance to ensure that these algorithms have been deprecated. Section 7. Editorial. Grammar. OLD In addition, the use of the SHA-256 hash algorithm is RECOMMENDED, SHA-1 or MD5 MUST NOT be used NEW In addition, the use of the SHA-256 hash algorithm is RECOMMENDED; and SHA-1 or MD5 MUST NOT be used Section 10.2 Please make RFC5246 a normative reference.


Question: IANA is requested to register the following Service Names: <ins> 7.5. The IANA is requested to list the name "masa" in the MUD extensions registry defined in I-D.ietf-opsawg-mud.  Its use is documented in mud-extension. </ins> 8. 8.1.

(n.b., i was not able to "make" and test the change, due to external pyang dependencies of some form.


Question: compromised parties refresh their credentials securely. Beware that in both oracle and private key access, an active adaptive <del> attacker, can follow the protocol and request to update its own </del> <ins> attacker can follow the protocol and request to update its own </ins> credential.  This in turn induces a signature key rotation which could provide the attacker with part or the full value of the private key depending on the architecture of the service provider.


Question: wishes to open an IP forwarding tunnel with no target or protocol limitations, it could send the following request: <del> 4.2. </del> <ins> 4.3. </ins> The IP proxy indicates a successful response by replying with the following requirements:

I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.


Question: shown with a '*'.  Once completed, endpoints are able to exchange application data. <del> An endpoint validates support for Explicit Congestion Notification (ECN) by observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in ecn-validation. </del> <ins> Endpoints can use packets sent during the handshake to test for Explicit Congestion Notification (ECN) support; see ecn.  An endpoint validates support for ECN by observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in ecn-validation. </ins> Endpoints MUST explicitly negotiate an application protocol.  This avoids situations where there is a disagreement about the protocol

This is my best stab at it.
Erik Kline said:
I thought that section reference was wrong, but Section 7 does indeed mention ECN twice. Once is almost too much for this section. I checked the history and the commits that affected this text likely are the result of a merge, and one that either git resolved incorrectly for us, or one that we messed up. Either way, this is worth fixing.
one nit


Question: Specify a Local Endpoint using a local interface name and local port: <ins> As an alternative to specifying an interface name for the Local Endpoint, an application can express more fine-grained preferences using the "Interface Instance or Type" Selection Property, see prop- interface.  However, if the application specifies Selection Properties which are inconsistent with the Local Endpoint, this will result in an error once the application attempts to open a Connection. </ins> Specify a Local Endpoint using a STUN server: Specify a Local Endpoint using a Any-Source Multicast group to join

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!


Question: QUIC's stream multiplexing feature allows applications to run multiple streams over a single connection, without head-of-line blocking between streams, associated at a point in time with a single <del> five-tuple.  Stream data is carried within Frames, where one (UDP) packet on the wire can carry one of multiple stream frames. Stream can be independently open and closed, gracefully or by error. If a critical stream for the application is closed, the application can generate respective error messages on the application layer to inform the other end or the higher layer and eventually indicate QUIC to reset the connection.  QUIC, however, does not need to know which streams are critical, and does not provide an interface to exceptional handling of any stream.  There are special streams in QUIC that are used for control on the QUIC connection, however, these streams are not exposed to the application. </del> <ins> five-tuple.  Stream data is carried within Frames, where one QUIC packet on the wire can carry one or multiple stream frames. Streams can be unidirectional or bidirectional, and a stream may be initiated either by client or server.  Only the initiator of a unidirectional stream can send data on it.  Due to offset encoding limitations, a stream can carry a maximum of 2^62-1 bytes in each direction.  In the presently unlikely event that this limit is reached by an application, the stream can simply be closed and replaced with a new one. Streams can be independently opened and closed, gracefully or by error.  An application can gracefully close the egress direction of a stream by instructing QUIC to send a FIN bit in a STREAM frame.  It cannot gracefully close the ingress direction without a peer- generated FIN, much like in TCP.  However, an endpoint can abruptly close either the ingress or egress direction; these actions are fully independent of each other. If a stream that is critical for an application is closed, the application can generate respective error messages on the application layer to inform the other end and/or the higher layer, and eventually indicate QUIC to reset the connection.  QUIC, however, does not need to know which streams are critical, and does not provide an interface for exceptional handling of any stream. </ins> Mapping of application data to streams is application-specific and <del> described for HTTP/s in QUIC-HTTP.  In general data that can be </del> <ins> described for HTTP/3 in QUIC-HTTP.  In general, data that can be </ins> processed independently, and therefore would suffer from head of line blocking if forced to be received in order, should be transmitted <del> over different streams.  If the application requires certain data to be received in order, the same stream should be used for that data. </del> <ins> over separate streams.  If the application requires certain data to be received in order, that data should be sent on the same stream. </ins> If there is a logical grouping of data chunks or messages, streams can be reused, or a new stream can be opened for each chunk/message. If one message is mapped to a single stream, resetting the stream to

This document should mention unidirectional streams Some words about the meaning of an abort signal vs. a clean close would be useful, both ingress and egress. Maximum stream bytes = 2^62-1. Saying "there are special streams for QUIC" is inaccurate (it's just one stream now, conceptually), and I would not bother to describe the CRYPTO frames this way.
Also: stream aborts are always unidirectional. what can/should applications assume about stream IDs? are they accessible, and does the app have any control over them?


Question: The syntax for the URI schemes in this section are specified using Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions of <del> "host", "port", "path-abempty", and "query" are adopted from RFC3986. </del> <ins> "host", "port", "path-abempty", "query", and "fragment" are adopted from RFC3986. </ins> Section 8 (Multicast CoAP) in RFC7252 is not applicable to these schemes.

Do we need to include the RFC7252 note for emphasis?
Probably not, as we are not changing anything about 5.10.1, are we? (But then 7.5 also points out a place where we maintain a property of 5.10.1.) ((But then, again, where would be put this?))
We need to identify the ABNF fragments as ABNF as in so they become easier to check in BAP.
We could add the note to Section 7, right after the new reference to "fragment":
Merged in abnf annotations from
is relevant to Section 7.
Good point. So I assume applying the same fix (add »[ "#" fragment ]«) four times to the ABNF in 7.1 to 7.4 would fix that? (We probably want to line-break before path-abempty in all four cases.)
If would be helpful to have more context for how the fragment identifier is used in CoAP. I don't see much detail in RFC7252 besides: Note: Fragments ([RFC3986], Section 3.5) are not part of the request URI and thus will not be transmitted in a CoAP request.
Fragment identifiers are not used in a transfer protocol; their use is a local matter on the client side. The mistake we made in RFC 7252 is providing ABNF that doesn't show fragment identifiers at all in the URI syntax. While CoAP as a protocol does not care about them, they are intended to be allowed in CoAP URIs so they can indeed be used on the client side. The note mentions this, but the ABNF does not reflect that. Same for coap-tcp-tls. Does it matter? The meaning of fragment identifiers is defined by the media type. So far, there has been little use of fragment identifiers in the media types being used with CoAP. Now, SenML actually does go ahead and defines a meaning for them, and other media types in the future might as well. So it would be good if the ABNF in the CoAP standards did not give the impression fragment identifiers cannot be used at all with CoAP URIs.


Question: The syntax for the URI schemes in this section are specified using Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions of <del> "host", "port", "path-abempty", and "query" are adopted from RFC3986. </del> <ins> "host", "port", "path-abempty", "query", and "fragment" are adopted from RFC3986. </ins> Section 8 (Multicast CoAP) in RFC7252 is not applicable to these schemes.

Note from Carsten: We may have to reopen that issue based on the about-face that the HTTP WG made here:
From URL which references: Absolute URI Some protocol elements allow only the absolute form of a URI without a fragment identifier. For example, defining a base URI for later use by relative references calls for an absolute-URI syntax rule that does not allow a fragment. absolute-URI = scheme ":" hier-part [ "?" query ] URI scheme specifications must define their own syntax so that all strings matching their scheme-specific syntax will also match the grammar. Scheme specifications will not define fragment identifier syntax or usage, regardless of its applicability to resources identifiable via that scheme, as fragment identification is orthogonal to scheme definition. However, scheme specifications are encouraged to include a wide range of examples, including examples that show use of the scheme's URIs with fragment identifiers when such usage is appropriate. and URL further states: Requirements for Permanent Scheme Definitions This section gives considerations for new schemes. Meeting these guidelines is REQUIRED for 'permanent' scheme registration. 'Permanent' status is appropriate for, but not limited to, use in standards. For URI schemes defined or normatively referenced by IETF Standards Track documents, 'permanent' registration status is REQUIRED. [RFC3986] defines the overall syntax for URIs as: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] A scheme definition cannot override the overall syntax for URIs. For example, this means that fragment identifiers cannot be reused outside the generic syntax restrictions and that fragment identifiers are not scheme specific. A scheme definition must specify the scheme name and the syntax of the scheme-specific part, which is clarified as follows: URI = scheme ":" scheme-specific-part [ "#" fragment ] scheme-specific-part = hier-part [ "?" query ] On Jan 28, 2015, at 1:56 PM, Julian Reschke wrote: The answer is "no". URL I don't know how I got beaten into submission on that for RFC7230. ....Roy


Question: This section considers an adversary who can add or remove responses to the SVCB query. <del> Clients MUST authenticate the server to its name during secure transport establishment.  This name is the hostname used to construct the original SVCB query, and cannot be influenced by the SVCB record contents.  Accordingly, this draft does not mandate the use of DNSSEC.  This draft also does not specify how clients authenticate the name (e.g. selection of roots of trust), which might vary according to the context. </del> <ins> During secure transport establishment, clients MUST authenticate the server to its authentication name, which is not influenced by the SVCB record contents.  Accordingly, this draft does not mandate the use of DNSSEC.  This draft also does not specify how clients authenticate the name (e.g. selection of roots of trust), which might vary according to the context. </ins> Although this adversary cannot alter the authentication name of the service, it does have control of the port number and "dohpath" value.

This should help with the case in DDR. See URL
Much better. Thanks for indulging me.


Question: the RTCP transmission for this media section to use reduced- size RTCP, as specified in RFC5506. <ins> [TODO: enable appropriate rtcp-fb mechanisms] </ins> If the directional attribute in the answer is of type "sendrecv" or "sendonly", prepare to start transmitting media <del> using the specified primary SSRC and one of the selected payload types, once the underlying transport layers have been established.  If RID values are specified, include the RID header extension in the RTP streams, as indicated in I-D.ietf- mmusic-rid, Section 4).  If simulcast is negotiated, send the number of Source RTP Streams as specified in I-D.ietf-mmusic- sdp-simulcast, Section 6.2.2.  If the directional attribute is of type "recvonly" or "inactive", stop transmitting RTP media, although RTCP should still be sent, as described in RFC3264, Section 5.1. </del> <ins> using the most preferred media format from the remote description that is also present in the answer, as described in RFC3264, Sections 6.1 and 7, once the underlying transport layers have been established.  [TODO: add discusssion of RED/FEC/RTX/CN] The payload type mapping from the remote description is used to determine payload types for the outgoing RTP streams.  Any RTP header extensions that were negotiated should be included in the outgoing RTP streams, using the extension mapping from the remote description; if the RID header extension has been negotiated, and RID values are specified, include the RID header extension in the outgoing RTP streams, as indicated in I-D.ietf-mmusic-rid, Section 4).  If simulcast is negotiated, send the number of Source RTP Streams as specified in I-D.ietf-mmusic-sdp-simulcast, Section 6.2.2. If the directional attribute is of type "recvonly" or "inactive", stop transmitting RTP media, although RTCP should still be sent, as described in RFC3264, Section 5.1. </ins> If the media section proto value indicates use of SCTP:

Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format. [TODO - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM


Question: hash.  The client instance will use this value to validate the "finish" call. <del> The AS MUST send the hash and interaction reference based on the interaction finish mode as described in the following sections. </del> <ins> All interaction finish methods MUST define a way to convey the hash and interaction reference back to the client instance.  When an interaction finish method is used, the client instance MUST present the interaction reference back to the AS as part of its continue- after-interaction. </ins> Note that in many error cases, such as when the RO has denied access, the "finish" method is still enacted by the AS.  This pattern allows

NAME Please take a look at this updated text to see if it addresses your concerns.
To edit notification comments on pull requests, go to your .
Thinking about possible extensions to GNAP's interaction modes, I had the impression that the specification could be a bit clearer regarding requirements on such extensions. From reading Section 3.3, my understanding is that all implementations of GNAP, including ones using extensions which define additional interaction finish methods, MUST include a nonce in the grant response (given that the AS wants to use the finish method offered by the client instance): URL However, Section 3.3.5 sounds a bit different, only referring to the two interaction finish methods defined by GNAP core: URL Section 4.2 could be a bit clearer as to what is expected of future extensions to GNAP, it currently says: URL with the two following sections describing the finish methods defined by GNAP core. This is, however, somewhat clearer in Section 4.2.3: I.e., Section 4.2.3 implies that AS must (somehow) provide the client instance with an interaction reference and interaction finish nonce. But it may be helpful to make this more explicit throughout the relevant Sections. There seem to be no requirements for future interaction start methods. It may be helpful to document some minimal requirements, e.g., enough information to identify the grant has to be conveyed to AS via RO in the interaction start (such as the redirect URI in GNAP core).
Thanks NAME for taking the time! The proposed text looks good to me (just one possible typo, I'm not a native speaker, so I'm not 100% sure about that).


Question: connections are not supported by the transport protocol, the system should fall back to bidirectional transport. <ins> 5.2.12. This property specifies how long to wait before aborting a Connection during establishment. </ins> 5.3. Most security parameters, e.g., TLS ciphersuites, local identity and

Notable changes: added control over using multipath (which was a late addition to minset) added a timeout for conn. establishment, separate from the other conn. abort timeout (see ) renamed InitiateWithIdempotentSend into InitiateWithSend, and adjusted the text to recommend declaring idempotence. This addresses the minset function that goes back to TCP's send-with-SYN.
Status: NAME said "LGTM modulo tiny nits" and I think these nits are now addressed. NAME requests something more than just a boolean to enable/disable usage of multiple paths. It seems to me that this needs more discussion, but it also doesn't seem like a show-stopper for the boolean to begin with; I think we can discuss this more after landing this PR. NAME hasn't reacted (or am I missing this), but this has an ok from NAME and NAME In conclusion: I think this is good to go. I'll wait until tomorrow; unless someone speaks up by then, I'll merge this PR.
If you make it a boolean it cannot be used as a selection property, so I do not think that is a good choice. Or how should it be interpreted for the selection?
NAME what do you mean, that it should be a (binary - yes/no) Preference instead? I thought this would be more limiting but I'm fine with this as well.
NAME I meant that it should be a Preference as pointed out in the original comment by NAME I do not understand what a boolean means during selection (is it a requirement or a preference?) I also do not understand what it means in the middle of a connection. You mean you should try and use a single or several subflows for scheduling data, assuming you already have a multipath connection? I guess this is possible, but then the description needs to be more clear that this is what it means. In the appendix about minset your have "Disable MPTCP: "Parallel Use of Multiple Paths" Property." I assume this refers to the Protocol Selection phase? It does not make sense to disable or enable MPTCP in the middle of a connection I think. I guess part of how to specify the property depends on how to interpret this part from the intro to the Managing Connections section: "The application can set and query Connection Properties on a per-Connection basis.


Question: connections are not supported by the transport protocol, the system should fall back to bidirectional transport. <ins> 5.2.12. This property specifies how long to wait before aborting a Connection during establishment. </ins> 5.3. Most security parameters, e.g., TLS ciphersuites, local identity and

Connection Properties that are not read-only can be set during pre-establishment (see {{selection-props}}), as well as on connections directly using the SetProperty action" I interpreted this as properties set during pre-establishment are selection properties, but maybe this is not the intention as they may need to be expressed differently? If they are not intended as selection properties, we are missing a selection property for multipath I guess.
NAME Ok. That's what I meant, yes - but I agree that's not covered by the description, it really is a selection preference only as it's written now. OK (though you CAN do it with the "real" API, by closing subflows, but this goes beyond the spec'd protocol, and I'm also not sure it's a good idea, especially when limited to only enabling / disabling it altogether). I would have understood this as in your first interpretation: "properties set during pre-establishment are selection properties".
NAME Closing a subflow is not the same as disabling MPTCP to me. You will still be using MPTCP, only with a single subflow. And you can certainly not open a subflow unless MPTCP is already enabled. But seems we now have a common understanding.
NAME ack, we've converged. I just pushed a commit that turns the "Parallel Use of Multiple Paths" property into a Selection property.
these are a few minor changes to apply, and properties to add (e.g. "disable MPTCP")
this is done, yes?
No. But I'm planning to do a PR to address this issue this week.
Note that this also requires closing , which I re-opened with a concrete proposal to address something from minset.
LGTM modulo tiny nitsSorry, missed this until just now. Looks fine with me, I just have a small question and my 2 cents to the multipath discussion (which we can have at a later point).


Question: The Initial packet contains a long header as well as the Length and Packet Number fields.  The first byte contains the Reserved and <del> Packet Number Length bits.  Between the SCID and Length fields, there are two additional fields specific to the Initial packet. </del> <ins> Packet Number Length bits.  Between the Source Connection ID and Length fields, there are two additional fields specific to the Initial packet. </ins> A variable-length integer specifying the length of the Token field, in bytes.  This value is zero if no token is present.

Editorial NiTs when reviewing the invariant text. These NiTs address readability issues, and do not intend to change the meaning of the text.
Is there an associated issue?
Thanks Gorry, these are all quite helpful. 1) I understand the acronyms DCID and SCID, but these aren't really expanded on first use in sect 5.1. 2) There's mention of "the high bit", but there doesn't seem to be any statement of bit order saying. Is it worth declaring network byte/bit order earlier in section 4? This also clarifies the placement of fields within a byte, which was basically assumed knowledge otherwise. 3) Personally, I don't think: "The length of the Destination Connection ID is not specified" is a great choice of words. Surely, this needs to be specified somewhere for a protocol instance to use it? This reads better as something like: The length of the Destination Connection ID is not encoded in packets with a short header and is not constrained by this specification. 4) The brackets here seem to point to connection IDs in general, not the DCID "(see Section 5.3)". Is it worth writing that as "Connection IDs are described in Section 5", rather than use brackets? The same is true for versions. 5) In section 5.3: "the wrong endpoint" is taken as the wrong transport endpoint, but some of our IP and subIP colleagues would use the term endpoint for other uses, so one insertion of "transport" would perhaps help? 6) In the appendix A, this: "QUIC forbids acknowledgments of packets" - still has me wondering what is actually intended to be understood, because the list of bullets is not guarenteed ... : /The last packet before a long period of quiescence might be assumed to contain an acknowledgment (it should be assumed that QUIC could allow acknowledgments of packets that only contain ACK frames)/ I'm not sure what to say here I think the combination of not... forbids threw me off the meaning. Changes proposed in
Thanks for changing SCID/DCID to "Source Connection ID" and "Destination Connection ID", that seems like a good change.


Question: credentials, etc.  By handing out a URI using which is protected with TLS, the captive portal operator can attempt to reassure the user that the captive portal is not malicious. <del> Operating systems should conduct all interactions with the API in a sand-boxed environment and with a configuration that minimizes tracking risks. </del>

…ptive-portals/vIDCvkyKXdvMGjwvOHuTsSgFzt8/
LGTM, for this change to address 1/2 of the referenced comments.


Question: protocol state, cached path state, and heuristics, may be shared (e.g. across multiple connections in an application).  This provides efficiency and convenience for the application, since the Transport <del> System implementation can automatically optimize behavior. </del> <ins> Services implementation can automatically optimize behavior. </ins> There are several reasons, however, that an application might want to explicitly isolate some Connections.  These reasons include:

Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!


Question: using the TLS exporter interface RFC5705 (for TLS 1.3 this is defined in Section 7.5 of RFC8446). <del> All other parameters such as MSK and EMSK are derived in the same manner as with EAP-TLS RFC5216, Section 2.3.  The definitions are repeated below for simplicity: </del> <ins> All other parameters are derived in the same manner as with EAP-TLS RFC5216, Section 2.3.  The definitions are repeated below for simplicity: </ins> The use of these keys is specific to the lower layer, as described RFC5247.

Proposal to change the derivation of the EMSK and MSK individually and directly from TLS exporter. Defines new tags for this purpose.
Thanks!


Question: A hash function <del> A Diffie-Hellman finite-field group or elliptic curve </del> <ins> A Diffie-Hellman finite-field group or elliptic curve group </ins> An AEAD encryption algorithm

This PR begins filling in the IANA Considerations section, starting with a Ciphersuites registry. This addresses the concerns in as discussed at the interim (2019-10), namely by reserving for vendor use chunk of the code points space large enough to be selected at random without huge risk of collision (2^12 values). Depends on
Here's the Weekly Digest for : - - Last week 9 issues were created. Of these, 6 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 13 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 10 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 38 commits.


Question: A hash function <del> A Diffie-Hellman finite-field group or elliptic curve </del> <ins> A Diffie-Hellman finite-field group or elliptic curve group </ins> An AEAD encryption algorithm

:hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .*
Enable, e.g., P-256 with both AES-GCM and ChaChaPoly Re-use code points from TLS
We should discuss that today


Question: An "a=ice-options" line with the "trickle" option MUST be added, as specified in I-D.ietf-ice-trickle, Section 4. <ins> If WebRTC identity is being used, an "a=identity" line as described in I-D.ietf-rtcweb-security-arch, Section 5. </ins> The next step is to generate m= sections, as specified in RFC4566 Section 5.14.  An m= section is generated for each RtpTransceiver that has been added to the PeerConnection, excluding any stopped

I fixed the grammar and added some text about "subsequent verification"
Also see URL
What's the issue?
Someone thought we should talk about how to parse SDP with more than one identity line and handle that. I did not look, we may already have whatever we need in the draft but I just opened this so we would at least go check.
JSEP practice is just to put in placeholders and link to the defining draft, so we should punt the actual semantics in security-arch.
See email to rtcweb from Stefan Håkansson subject "Identity in the SDP"
Sayeth Stefan: >[2] URL


Question: 4.5. <del> Header blocks contain compressed representations of header lists and are carried in frames on streams defined by the enclosing protocol. These representations reference the static table, or dynamic table in a particular state without modifying it. </del> <ins> A header block consists of a prefix and a possibly empty sequence of representations defined in this section.  Each representation corresponds to a single header field.  These representations reference the static table or the dynamic table in a particular state, but do not modify that state. Header blocks are carried in frames on streams defined by the enclosing protocol. </ins> 4.5.1.

Use more uniform and more specific language in description of instructions, like "follows" instead of "includes" or implicit mention of a field. Add references to integer and string encodings where missing. Prefer internal references to external ones (also in Section 1.2). Explicitly allow a header block to not have any instructions after the mandatory prefix. Refer to Literal Header Field With Name Reference section in Literal Header Field Without Name Reference instead of verbatim repeating text on 'N' bit. Reshuffle sentences, insert references instead, remove sentences where references suffice.
Mostly good improvements; a few things to fix up further.


Question: Frame types which were used in HTTP/2 where there is no corresponding HTTP/3 frame have also been reserved (iana-frames).  These frame types MUST NOT be sent, and receipt MAY be treated as an error of <del> type HTTP_UNEXPECTED_FRAME. </del> <ins> type HTTP_FRAME_UNEXPECTED. </ins> 8.

This changes HTTPUNEXPECTEDFRAME, which is used only once, to HTTPFRAMEUNEXPECTED that is used multiple times.
During the London interim, it was noted that error codes refer to things being "malformed," "bad," "invalid," and "unexpected." Pick one and use it consistently, or establish precise definitions for each. This applies to both the current document and .
The three words are not equivalent: while both "malformed" and "invalid" are "bad," "malformed" is not the same as "invalid."
Minor correction here, "bad" is only used in . The only instance of "bad" in current document is a substring of example "0x1abadaba". I'll fix the PR before it lands, whatever order we end up doing things in.
The different value-judgement terms are corrected by the flurry of settings PRs that NAME already did. HTTPFRAMEERROR has replaced malformed, and UNEXPECTEDFRAME and WRONGSTREAM are reasonably descriptive (though see , ). We do still have some variation between HTTPTHINGDESCRIPTOR, HTTPTHINGERROR, and HTTPDESCRIPTORTHING (e.g. HTTPUNEXPECTEDFRAME versus HTTPREQUESTREJECTED) that might be worth reconciling. Is it worth turning into HTTPFRAMEUNEXPECTED?
Resolved by and something prior to it.
oops, thanks


Question: A signed object describing a client's identity and capabilities, and including a hybrid public-key encryption (HPKE I-D.irtf-cfrg- <del> hpke ) public key that can be used to encrypt to that client. </del> <ins> hpke) public key that can be used to encrypt to that client. </ins> A key package that is prepublished by a client, which other clients can use to introduce the client to a new group.

cc NAME
NAME is the build expected to fail?
No, but the problem seem unrelated to your change, so we are all good.
Looks like it was a transient failure. Re-running resulted in success.
NAME points out that the HPKE version is not pinned. This is probably needed for interop. Version -07 should come sometime this week, so that seems like a perfectly fine version to use. I can send a PR when that version is cut.
Fixed by


Question: Change Controller: IESG <del> 9.6. </del> <ins> 9.7. </ins> IANA has added the media type 'application/edhoc' to the CoAP Content-Formats registry.

(Last two commits on wrong branch.)
The prototype of EDHOC-Exporter() has remained EDHOC-Exporter(label, length), while it should be EDHOC-Exporter(label, context, length) as per Alternative 3 discussed in issue URL Correct?
Thanks NAME your comment is addressed in the latest commit. I merge this now.
The text use both the terms "session" and "protocol instance", would be good to settle for one term.
Just chose one, I don't think this needs an issue
In the security considerations "session" makes most sense to me. There is also the term "connection". I will make a proposal.
The spec should likely forbid multiple calls to the EDHOC-Exporter interface with the same label, in order to prevent the same key being reused. Discussed with NAME and NAME
Good catch. Yes, we should have some text about that, but it should probably more be a requirement on the application using EDHOC that on EDHOC itself. Two different application should defintly not use the same label. The same application might rederive the same key several times as long as it keep track of its AEAD nonces and replay window. I thought that we had already IANA registry proposed for this, but that is not the case. We should probably have one. If we have a IANA registry the labels get more fixed and it might be that we need a context input parameter as well.
If we make a IANA registrer for labels, I think we need to let the application add additional information in some way. Two alternatives: We make an IANA register for label prefixes, and let the application append information to the label prefix. This was recently planned for EAP-TLS (and methods built on EAP-TLS) but was changes because the TLS export labels are not really ment to be labels. This would not change the current exporter interface. We expand the interface with a context parameter. This is similar to the TLS exporter. A problem with the TLS exporter is that some implementations decided to not even support context.
NAME how is the context parameter intended to be used? Could you give an example? Would this be some sort of "salt" when deriving the key?
Don't register labels, register label prefixes.


Question: Change Controller: IESG <del> 9.6. </del> <ins> 9.7. </ins> IANA has added the media type 'application/edhoc' to the CoAP Content-Formats registry.

The motivation for "context" or "label postfixes" is to increase the flexibility for the application. Restricting the application to IANA registered labels is very limiting. An application might want to use the EDHOC exporter to derive a number of keys and we should encourage that. The alternative is that the application needs to implement its own key derivation, which might be less secure and might be outside of the TEE. I called it "context" just because TLS calls the paramater in its exporter context.
"Be like TLS" is of course a good motivation. Technically, a label prefix is not different from a context, it just saves the need to separate prefix and suffix.
(And of course there is nothing wrong with multiple calls with the same label; the application has a "right to forget" :-)
The solutions should be equal when it comes to security. The choice should be made based on what is easiest for implementators and apllications using EDHOC. Alt 1. We make an IANA register for label prefixes: "OSCORE Master Secret" "OSCORE Master Salt" The Export function stays the same: EDHOC-Exporter(label, length) = EDHOC-KDF(PRK4x3m, TH4, label, length) An application is allowed to append things to the label prefix: "OSCORE Master Secret" "OSCORE Master Secret PickleRick" Alt 2. We make an IANA register for labels: label = "OSCORE Master Secret" label = "OSCORE Master Salt" The Export function needs to change: EDHOC-Exporter(label, ctx, length) = EDHOC-KDF(PRK4x3m, TH4, [label, ctx] , length) An application is not allowed to append things to the label and uses the ctx instead: label = "OSCORE Master Secret" ctx = "" label = "OSCORE Master Secret" ctx = "PickleRick"
No major opinion. Alt 2 breaks the test vector for the OSCORE security context. It would be good to get more input.
Any preference NAME NAME NAME ?
If desired the CTX is more convenient it can always be added in a wrapper on top of EDHOC-Exporter(). (I assume re-use of label+ctx in Alt 2 is equivalent to re-use of label in Alt 1?)
I prefer to have explicitly specified.


Question: Change Controller: IESG <del> 9.6. </del> <ins> 9.7. </ins> IANA has added the media type 'application/edhoc' to the CoAP Content-Formats registry.

We can pass to the concatenation of and . When is undefined/empty, test vectors are not affected. I guess this is what NAME is referring to?
label is a CBOR byte string. While alt 2 use an CBOR array. Definging alt2 as a wrapper seems more complication in my view.
Would be good if people stated alt 1. or alt 2. or made a concrete suggestion for alt 3.
Alt 3 (CBOR sequence) We make an IANA register for labels: label = "OSCORE Master Secret" label = "OSCORE Master Salt" The Export function needs to change: EDHOC-Exporter(label, ctx, length) = EDHOC-KDF(PRK4x3m, TH4, labelcontext, length) where is a CBOR sequence: If you want to keep the test vectors intact, then you could make optional in the CDDL, but not sure how to specify an optional parameter in the interface definition.
Thanks. That is a valid alt 3. but ctx should probably be a bstr
I don't think keeping the test vectors intact is an important goal at all. Let's decide on what is simplest for a user of the exporter interface.
Something like that, yes. Later post do differentiate the type of "label" and "ctx" and in light of that and changing test vectors Alt3 seems clean.
I am fine with alt 3. I can start making PR for that unless somebody has different ideas. I don't alt 1 is a good alternative anymore as is restricts context to being a unicode string. Which would require some base64 encoding or similar for a general context.
Please review alt. 3 as specified in . Unless there are any comments we would like to merge this.
This is included in -07 so I close the issue.
Comment by Martin Disch in URL "The draft does a good job of pointing to the right places in RFC 8152, but I still ended up trying to understand another ~100 page document just to implement the few constructs I actually needed." Should we provide more details about COSE constructs, e.g. in appendix A.2?
(pasting my response from the mailing list here for completeness) Thanks for following up on this. Yes, in my opinion expanding on the COSE constructs would be helpful.