Question: 9. <ins> Extensions to CONNECT-IP can define behavior changes to this mechanism.  Such extensions SHOULD define new capsule types to exchange configuration information if needed.  It is RECOMMENDED for extensions that modify addressing to specify that their extension capsules be sent before the ADDRESS_ASSIGN capsule and that they do not take effect until the ADDRESS_ASSIGN capsule is parsed.  This allows modifications to address assignement to operate atomically. Similarly, extensions that modify routing SHOULD behave similarly with regards to the ROUTE_ADVERTISEMENT capsule. 10. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies

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: 9. <ins> Extensions to CONNECT-IP can define behavior changes to this mechanism.  Such extensions SHOULD define new capsule types to exchange configuration information if needed.  It is RECOMMENDED for extensions that modify addressing to specify that their extension capsules be sent before the ADDRESS_ASSIGN capsule and that they do not take effect until the ADDRESS_ASSIGN capsule is parsed.  This allows modifications to address assignement to operate atomically. Similarly, extensions that modify routing SHOULD behave similarly with regards to the ROUTE_ADVERTISEMENT capsule. 10. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies

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: 9. <ins> Extensions to CONNECT-IP can define behavior changes to this mechanism.  Such extensions SHOULD define new capsule types to exchange configuration information if needed.  It is RECOMMENDED for extensions that modify addressing to specify that their extension capsules be sent before the ADDRESS_ASSIGN capsule and that they do not take effect until the ADDRESS_ASSIGN capsule is parsed.  This allows modifications to address assignement to operate atomically. Similarly, extensions that modify routing SHOULD behave similarly with regards to the ROUTE_ADVERTISEMENT capsule. 10. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies

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: 9. <ins> Extensions to CONNECT-IP can define behavior changes to this mechanism.  Such extensions SHOULD define new capsule types to exchange configuration information if needed.  It is RECOMMENDED for extensions that modify addressing to specify that their extension capsules be sent before the ADDRESS_ASSIGN capsule and that they do not take effect until the ADDRESS_ASSIGN capsule is parsed.  This allows modifications to address assignement to operate atomically. Similarly, extensions that modify routing SHOULD behave similarly with regards to the ROUTE_ADVERTISEMENT capsule. 10. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies

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: 9. <ins> Extensions to CONNECT-IP can define behavior changes to this mechanism.  Such extensions SHOULD define new capsule types to exchange configuration information if needed.  It is RECOMMENDED for extensions that modify addressing to specify that their extension capsules be sent before the ADDRESS_ASSIGN capsule and that they do not take effect until the ADDRESS_ASSIGN capsule is parsed.  This allows modifications to address assignement to operate atomically. Similarly, extensions that modify routing SHOULD behave similarly with regards to the ROUTE_ADVERTISEMENT capsule. 10. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies

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: 9. <ins> Extensions to CONNECT-IP can define behavior changes to this mechanism.  Such extensions SHOULD define new capsule types to exchange configuration information if needed.  It is RECOMMENDED for extensions that modify addressing to specify that their extension capsules be sent before the ADDRESS_ASSIGN capsule and that they do not take effect until the ADDRESS_ASSIGN capsule is parsed.  This allows modifications to address assignement to operate atomically. Similarly, extensions that modify routing SHOULD behave similarly with regards to the ROUTE_ADVERTISEMENT capsule. 10. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies

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: 9. <ins> Extensions to CONNECT-IP can define behavior changes to this mechanism.  Such extensions SHOULD define new capsule types to exchange configuration information if needed.  It is RECOMMENDED for extensions that modify addressing to specify that their extension capsules be sent before the ADDRESS_ASSIGN capsule and that they do not take effect until the ADDRESS_ASSIGN capsule is parsed.  This allows modifications to address assignement to operate atomically. Similarly, extensions that modify routing SHOULD behave similarly with regards to the ROUTE_ADVERTISEMENT capsule. 10. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies

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: 9. <ins> Extensions to CONNECT-IP can define behavior changes to this mechanism.  Such extensions SHOULD define new capsule types to exchange configuration information if needed.  It is RECOMMENDED for extensions that modify addressing to specify that their extension capsules be sent before the ADDRESS_ASSIGN capsule and that they do not take effect until the ADDRESS_ASSIGN capsule is parsed.  This allows modifications to address assignement to operate atomically. Similarly, extensions that modify routing SHOULD behave similarly with regards to the ROUTE_ADVERTISEMENT capsule. 10. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies

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: In order to limit the attacks described in sec-ice-hammer, an ICE agent MUST limit the total number of connectivity checks the agent <del> performs across all check lists to a specific value, and this value MUST be configurable.  A default of 100 is RECOMMENDED.  This limit is enforced by discarding the lower-priority candidate pairs until there are less than 100.  It is RECOMMENDED that a lower value be utilized when possible, set to the maximum number of plausible checks that might be seen in an actual deployment configuration.  The requirement for configuration is meant to provide a tool for fixing this value in the field if, once deployed, it is found to be problematic. </del> <ins> performs across all check lists in the check list set.  This is done by limiting the total number of candidate pairs in the check list set.  The default limit of candidate pairs for the check list set is 100, but the value MUST be configurable.  The limit is enforced by, within in each check list, discarding lower-priority candidate pairs until the total number of candidate pairs in the check list set is smaller than the limit value.  The discarding SHOULD be done evenly so that the number of candidate pairs in each check list is reduced the same amount. It is RECOMMENDED that a lower limit value than the default is picked when possible, and that the value is set to the maximum number of plausible candidate pairs that might be created in an actual deployment configuration.  The requirement for configuration is meant to provide a tool for fixing this value in the field if, once deployed, it is found to be problematic. </ins> 6.1.2.6.

The following issues are addressed in this commit: URL URL
LGTM
To prevent one check list from starving.
This was discussed (and, as far as I am concerned, agreed) on the list 1st June. But, it's good to have a reminder :)
This one has not been addressed as far as I can tell. Now we get to decided if it's important enough or not to do something about :)
I had a look at this, but for some reason it never got implemented. I think it should be an easy fix.
The changes section looks very small compared to how many changes we've made, so it definitely needs updating. Now we need to decide whether we have to update it before or after requesting publication.
Yes - we just have to remember everything :) However, I don't think we should go into details: the major changes (that I can think of when writing this) are removal of regular/aggressive nomination, and the changes related to "Emil's table".
LGTM


Question: is a CDDL defined type, and Description is a text string.  The initial contents of the registry is shown in fig-error-codes. <del> 9.4. </del> <ins> 9.5. </ins> IANA has added the well-known URI 'edhoc' to the Well-Known URIs 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: is a CDDL defined type, and Description is a text string.  The initial contents of the registry is shown in fig-error-codes. <del> 9.4. </del> <ins> 9.5. </ins> IANA has added the well-known URI 'edhoc' to the Well-Known URIs 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: is a CDDL defined type, and Description is a text string.  The initial contents of the registry is shown in fig-error-codes. <del> 9.4. </del> <ins> 9.5. </ins> IANA has added the well-known URI 'edhoc' to the Well-Known URIs 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.


Question: is a CDDL defined type, and Description is a text string.  The initial contents of the registry is shown in fig-error-codes. <del> 9.4. </del> <ins> 9.5. </ins> IANA has added the well-known URI 'edhoc' to the Well-Known URIs registry.

But I also sympathize with not wanting to duplicate what is already defined in another RFC (and possibly getting it wrong, as Carsten points out). Considering that there are quite a few implementers already and besides mine you have only received one other similar comment, maybe this isn't an issue for a meaningful majority. In any case, the draft has made great strides already in terms of accessibility and is in a good state now, so I don't see improvements in this area as an absolute necessity.
The two COSE constructs that are used in EHDOC, and are fairly simple. They don't use the recursive structure or embed . I think it is possible to add some additional clarifications on the structure of the COSE messages in the EHDOC draft without having to copy too much text from RFC 8152. As part of a thesis I built a proof-of-concept implementation of EDHOC in the Rust programming language available at URL The naming of the repository is due to the subject being both EDHOC and OSCORE on embedded devices, but the following refers only to the EDHOC implementation. It's based on draft-selander-ace-cose-ecdhe-14 and as such, sadly, outdated. Since it was just one part of the overall work, I only managed to implement the subset I needed, which is RPK and the signature-signature based scheme (corresponding to what draft-selander-lake-edhoc calls method 0). I also took some other shortcuts, such as not supporting auxiliary data. Fortunately, test vectors were about to be introduced just around the time I was working on it, so I've been able to successfully verify my implementation against them when John shared them with me for some preliminary testing. Since I didn't have any prior experience implementing this kind of software, I would definitely consider it more of an experiment, but it's out there and it works, in case it can be useful to anybody. I'm convinced that EDHOC will be valuable particularly in the context of OSCORE, possibly even beyond that. As for the draft itself, I would like to mention one aspect that I think could be improved from the perspective of an implementer. Part of the promise of EDHOC is that it's simple and lightweight due to reusing COSE.


Question: is a CDDL defined type, and Description is a text string.  The initial contents of the registry is shown in fig-error-codes. <del> 9.4. </del> <ins> 9.5. </ins> IANA has added the well-known URI 'edhoc' to the Well-Known URIs registry.

That is certainly the case, but breaks down somewhat when working on a system where no fully featured library for it is available. This was the case for me and I personally found it difficult to quickly figure out which aspects of COSE I needed to implement. 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. I know the authors are aware of this and there has been some effort to inline more information directly in the specification, which I greatly appreciate. It would be very nice to have an entirely self-contained document to work with. But I have to again point out my lack of experience in that area, it's entirely possible that this draft is in fact much better than others in this regard and I just don't know it yet. With that I would like to support the adoption and am looking forward to seeing how it develops. Kind regards, Martin


Question: This limit does act as an additional constraint on datagram size in the same way as the path MTU, but it is a property of the <del> endpoint and not the path; see packet-size.  It is expected that </del> <ins> endpoint and not the path; see datagram-size.  It is expected that </ins> this is the space an endpoint dedicates to holding incoming packets.

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


Question: This limit does act as an additional constraint on datagram size in the same way as the path MTU, but it is a property of the <del> endpoint and not the path; see packet-size.  It is expected that </del> <ins> endpoint and not the path; see datagram-size.  It is expected that </ins> this is the space an endpoint dedicates to holding incoming packets.

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


Question: 21.12.1. The QUIC handshake incorporates the TLS 1.3 handshake and enjoys the <del> cryptographic properties described in Appendix E.1 of TLS13. </del> <ins> cryptographic properties described in Appendix E.1 of TLS13.  Many of the security properties of QUIC depend on the TLS handshake providing these properties.  Any attack on the TLS handshake could affect QUIC. </ins> <del> In addition to those properties, the handshake is intended to provide some defense against DoS attacks on the handshake, as described below. </del> <ins> Any attack on the TLS handshake that compromises the secrecy or uniqueness of session keys affects other security guarantees provided by QUIC that depends on these keys.  For instance, migration (migration) depends on the efficacy of confidentiality protections, both for the negotiation of keys using the TLS handshake and for QUIC packet protection, to avoid linkability across network paths. An attack on the integrity of the TLS handshake might allow an attacker to affect the selection of application protocol or QUIC version. In addition to the properties provided by TLS, the QUIC handshake provides some defense against DoS attacks on the handshake. </ins> 21.12.1.1.

We don't ever really say that QUIC depends on TLS providing the properties that we claim TLS provides. So it's worth pointing that exposure. This is more so because some of the properties we claim are dependent on these properties.
(Cleaned up duplicate instances of the same comment.)
As per comment URL I'll note that there is MITM protection in QUIC, but it is not immediate which is roughly why we have the concept of handshake confirmed.
The options for triage are close it, mark as editorial, or mark as design. This has a needs-discussion, and I'm seeing a lack of any discussion. So you might see where my thought process is going... NAME this relates to your PR on the QUIC threat model. Are you willing to provide some comment that helps us triage the issue?
I think that we can take this as editorial, as it merely requires that we capture already agreed principles (we don't protect against an adversary who can inject packets). NAME assistance would be useful, but I can produce text if nothing is forthcoming.
I can always provide comments, no guarantees on how much they'll help triage IIRC, this is an issue filed from a comment on the threat model PR that was several-months merged to potentially increase the scope of what that covered. I think that the original threat model that NAME and I put together, covering the handshake and migration respectively, is intended to be the start of that section -- as additional items are discovered that could use coverage there to help clarify QUIC's stance on whatever issue, they should totally be added. I agree with NAME that adding such items seem editorial, as they aren't introducing any new requirements and are only capturing current realities as specified elsewhere. (Of course, as that text is written, it seems logical that putting it all in words next to each other may highlight issues, and if the WG decides that we don't like how the current spec results in a particular security stance, we can open a design issue to change normative text elsewhere.) So, I'd probably consider this editorial, and ask NAME to potentially contribute some text or clarify what he's looking to have covered by the original comment -- once that's clear, happy to help get a PR up if needed (or NAME text is always good too!).


Question: 21.12.1. The QUIC handshake incorporates the TLS 1.3 handshake and enjoys the <del> cryptographic properties described in Appendix E.1 of TLS13. </del> <ins> cryptographic properties described in Appendix E.1 of TLS13.  Many of the security properties of QUIC depend on the TLS handshake providing these properties.  Any attack on the TLS handshake could affect QUIC. </ins> <del> In addition to those properties, the handshake is intended to provide some defense against DoS attacks on the handshake, as described below. </del> <ins> Any attack on the TLS handshake that compromises the secrecy or uniqueness of session keys affects other security guarantees provided by QUIC that depends on these keys.  For instance, migration (migration) depends on the efficacy of confidentiality protections, both for the negotiation of keys using the TLS handshake and for QUIC packet protection, to avoid linkability across network paths. An attack on the integrity of the TLS handshake might allow an attacker to affect the selection of application protocol or QUIC version. In addition to the properties provided by TLS, the QUIC handshake provides some defense against DoS attacks on the handshake. </ins> 21.12.1.1.

Since this concerns the handshake, I'm not too confident in contributing text but I'd be happy to review and discuss. I believe it is correct that the issue is covered in existing text elsewhere but as NAME says, it makes sense to cover it in one place. The risk is that the reader is not aware how important it is to reach a certain point in the connection before trusting data, and especially to those seeking to create derived versions. From various discussions I'm not sure the importance is broadly understood. Additionally, I'm not entirely convinced that the current text fully captures the problem - not that we necessarily can - for example various stateless transmissions / redirects / token issues - might assume a level of privacy that doesn't exist in all cases, thus requiring stronger integrity elsewhere such as in CIDs, tokens etc..
Thanks folks. It seems we have a path forward, so I'm removing the needs-discussion label. The editorial process will naturally generate some back and forth but that is the same for all editorial issues.


Question: The CONNECTION_CLOSE frame provides an optional reason field, that can be used to append human-readable information to an error code. <del> Note that QUIC RESET_STREAM and STOP_SENDING frames also include an error code, but no reason string.  Application error codes are expected to be defined from a single space that applies to all three frame types. </del> <ins> RESET_STREAM and STOP_SENDING frames also include an error code, but no reason string. </ins> Alternatively, a QUIC connection can be silently closed by each endpoint separately after an idle timeout.  If enabled as indicated

Thanks to Mike for noticing this.
This is true, but there is nothing inherent to the design that prevents RESETSTREAM (and STOPSENDING) from using a different code space from CONNECTION_CLOSE. Though we have the policy in HTTP/3 that any stream error can become a connection error, the same isn't necessarily true of other protocols. Maybe we cab just avoid mentioning this possibility..,
I don't think I have a strong opinion on removing or keeping this sentence. Would it be any better if we say: "Application error codes are recommended to be defined from a single space that applies to all three frame types." ? Or is there any other guidance we can or want to give to application designer about the use of error codes?


Question: Selection properties are represented as preferences, which can have one of five preference levels: <ins> In addition, the pseudo-level "Default" can be used to reset the property to the default level used by the implementation.  This level will never show up when queuing the value of a preference - the effective preference must be returned instead. </ins> Internally, the transport system will first exclude all protocols and paths that match a Prohibit, then exclude all protocols and paths that do not match a Require, then sort candidates according to

This closes issue
Weren't we supposed to stop making PRs and issues until March 5? See Zahed's email to the TAPS list
NAME sorry – I did not read list mails since yesterday morning.
Yes, let's hold off on these until we move repos!
We discussed the use of a "Default" preference level that restores the system default in . In addition, we should check whether we really need to fix the default values for all Selection Properties in the API document or can make some of them to be "Implementation Specific".
Closed by PR
Looks good to me.


Question: response to receiving a Retry. A client MUST NOT reset the packet number for any packet number space <del> after processing a Retry packet; packet-0rtt contains more information on this. </del> <ins> after processing a Retry packet.  In particular, 0-RTT packets contain confidential information that will most likely be retransmitted on receiving a Retry packet.  The keys used to protect these new 0-RTT packets will not change as a result of responding to a Retry packet.  However, the data sent in these packets could be different than what was sent earlier.  Sending these new packets with the same packet number is likely to compromise the packet protection for those packets because the same key and nonce could be used to protect different content. </ins> A server acknowledges the use of a Retry packet for a connection using the retry_source_connection_id transport parameter; see

This moves text from the section on 0-RTT to the section on continuing after Retry. Though 0-RTT is the only thing that is seriously affected in the current design, Initial packets might also be affected if we ever wanted to protect those with anything other than a static key.
says that after receiving a Retry, clients MUST NOT reset the packet number for any packet number space, and references 17.2.3 for more info. However, 17.2.3 only explains why this is the case for 0-RTT packets. We should either narrow the prohibition or expand the explanation.
Or maybe move the explanation that currently exists 17.2.3 to 17.2.5.3 and use it as an example (to avoid it being read as the only reason).
NAME does NAME editorial change address your issue?
Yes, this is fine.


Question: notification provider have to be trusted to avoid making correlation on which devices are recipients of the same message. <del> For secure messaging systems, push notification are often sent real- </del> <ins> For secure messaging systems, push notifications are often sent real- </ins> time as it is not acceptable to create artificial delays for message retrieval.

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: encrypt or (successfully) decrypt a message or <del> if a key, nonce or secret derived from S has been consumed.  (This goes both for values derived via Derive-Secret and HKDF-Expand- Label). </del> <ins> if a key, nonce or secret derived from S has been consumed. (This goes both for values derived via Derive-Secret and HKDF-Expand- Label.) </ins> Here, S may be the init_secret, update_secret, epoch_secret, application_secret as well as any secret in the AS Tree or one of the

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: publication, the early allocation will be deprecated in favor of this assignment. <ins> A new column "DTLS-Only" is added to the registry.  The valid entries are "Y" if the extension is only applicable to DTLS, "N" otherwise. All the pre-existing entries are given the value "N". </ins> Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document describes the behavior of this extension for DTLS 1.2 only; it is not

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


Question: Authorization Data" under the new group name "Ephemeral Diffie- Hellman Over COSE (EDHOC)".  The registration procedure is "Specification Required".  The columns of the registry are Label, <del> Message, Description, and Reference, where Label is an integer and the other columns are text strings. </del> <ins> Description, and Reference, where Label is a positive integer and the other columns are text strings. </ins> 9.6.

Addressing
Issue needed.
Should we allow or forbid that eadlabel = k and eadlabel = -k correspond to different ead-values? For example, if an (eadlabel, eadvalue) is always critical: Say, eadvalue is an ACE Access Token with eadlabel = -4, always critical. Then we can either: forbid the use of eadlabel = 4 altogether, or allocate an always non-critical EAD to eadlabel = 4, say, eadvalue is "service indication" as in In case 1 we will have some "holes" in the register. One positive integer blocked for each always critical (eadlabel, eadvalue) , one negative blocked for each always non-critical (eadlabel, eadvalue), and 0 cannot be used. (It is not clear to me that there are many always non-critical, but always critical is probably common.) In case 2, we could still have the registration policy that: if an EAD can be either critical or non-critical then two eadlabel with same absolute value should be reserved for it. What is the main risk with case 2? If someone misunderstands or by accident changes sign on an always /non-/critical EAD this results most likely in an error due to wrong eadvalue (like in the example above), but potentially in an unintended EAD message. (Another registration policy could be that the eadvalues corresponding to ead_labels k and -k should have incompatible CDDL so the error is discovered ...) The EAD specification needs anyway to specify what are the processing rules and if you violate those more or less anything could happen. Comments?
BTW, we may want a term for the ordered pair (eadlabel, eadvalue). The term "EAD" or "EAD field" is referring to the message field, which may consist of multiple (eadlabel, eadvalue).
Just seems like overoptimization to me. I would prefer if we follow the model that we agreed on for C509 which is similar to what CoAP Options is using. If you think it is important to use the complete code point space I think it would be better not assign any functionality to the minus sign and register critical and non-critical idenpendently. The original proposal seems to give two different meanings to the minus sign.


Question: Authorization Data" under the new group name "Ephemeral Diffie- Hellman Over COSE (EDHOC)".  The registration procedure is "Specification Required".  The columns of the registry are Label, <del> Message, Description, and Reference, where Label is an integer and the other columns are text strings. </del> <ins> Description, and Reference, where Label is a positive integer and the other columns are text strings. </ins> 9.6.

The minus value is either a criticallity toggle or a completly different EAD.
Introducing the term "EAD item" for (eadlabel, eadvalue)
Edit: Let's include the main points of this PR in -15 as a input to the design team meeting.
I made a proposal. The text now include the concepts "EAD item" and "critical"/"non-critical" EAD item. There is also more details about how applications makes use of EAD: each application registers its own eadlabels eadlabel is a positive integer associated to a particular eadvalue if the application transports different eadvalues then multiple eadlabels need to be registered the application specifies how EAD items are transported in EDHOC messages, a particular EAD item may be transported in multiple messages (i.e. different EADx). I'll merge this into -15 and look forward to comments!
There is a new PR suggesting this. There is no background discussion in the PR . There would be good with some use case. The definition of what critical need and how the recipient handles critical would need a lot of discussion and fine-tuning.The handling of critical extensions in C.509 is to my understanding confusing and problematic. Both in the specification and in implementations.
Please see for background discussion and use cases.
Seems very unclear that the current PR can be the basis for a ECH type mechanism. PR should motivate why it is the basis for an ECH type mechanism or we should have some discussion regarding use cases for a general critical non-critical EAD mechanism. I do not see that follow from .
Having critical/non-critical EAD seems like a reasonable thing in its own, but it is not clear to me that it is a step on the way to a ECH mechanism in EDHOC.
Should we add another column in IANA register? Type: always critical / always non-critical / application determines criticality
If we define such a Type, the following text can be removed from specification and replaced by IANA consideration: "A specification registring a new EAD label MUST describe if the EAD item is always critical, always non-critical, or if it can be decided by the application in the sending endpoint."
I merged which addresses some points raised in this issue. Please review and comment if there is anything missing.


Question: Authorization Data" under the new group name "Ephemeral Diffie- Hellman Over COSE (EDHOC)".  The registration procedure is "Specification Required".  The columns of the registry are Label, <del> Message, Description, and Reference, where Label is an integer and the other columns are text strings. </del> <ins> Description, and Reference, where Label is a positive integer and the other columns are text strings. </ins> 9.6.

The consequences of EDHOC processing of critical / non-critical EAD items is described, but how the security application makes use of this property is left to the associated specification. (In particular, no registration of criticality in the IANA register.)
This is motivated by two considerations, the concerns for clients selecting a hidden service in a protected way (pinging NAME do you have a pointer to your hackathon project), and TLS's encrypted Client Hello (superseding eSNI, encrypted server name indication). The rough situation for either case is that a client has some out-of-band information about the server that includes a public key for encryption (even if the encryption key on its own may be insufficient to authenticate the server). As a straw man proposal (mainly as scaffolding for the "how to enable it" steps later), consider the following: (I bet that reading the will give valuable input for making this complete). To ensure that responders (who are, in their identity selection, the more exposed side) can't be probed for their support of encrypted EAD, encrypted EAD should be marked as "elective" in the sense that a server may ignore it if it does not support it. (It'd still become part of the transcript). If a server receives an EAD it can not decrypt (or which, after decryption, contains nothing valid, eg. because the wrong GE was used), it needs to just continue and pick the CREDR / IDCREDR it would always have picked. AIU we do not yet distinguish between EAD that are elective and those that are critical. I do not know whether we'll even have any "critical" ones (as the peer's lack of action on them should be enough indication that they were unsupported), but if we do distinguish (eg. along the positive/negative number line), encrypted EAD should be optional. This has the upside that initiators that can spare the few bytes can always include some random bytes in the encrypted EAD, and thus ensure that actual users of encrypted EAD do not stand out (or that connections with encrypted EAD would be blocked). It should be a design goal of encrypted EAD that any use of EAD can always be plausibly claimed to just be random bytes added because the specification says one should do that ever now and then.


Question: Authorization Data" under the new group name "Ephemeral Diffie- Hellman Over COSE (EDHOC)".  The registration procedure is "Specification Required".  The columns of the registry are Label, <del> Message, Description, and Reference, where Label is an integer and the other columns are text strings. </del> <ins> Description, and Reference, where Label is a positive integer and the other columns are text strings. </ins> 9.6.

For a practical example, a vulnerable service (say, anything civil rights related) might be operated at the same IP address as a more wide-spread service (say, a large public LwM2M provider). The civil rights service would publish its address together with the public key GE and its service name in DNS records similar to . A client contacting it would start an EDHOC exchange with the public address and encrypt the service name with GEX in the EAD1. The server would respond with credentials for the civil rights service, to which the client then may either present an anonymous (CCS) identity, or (now that it knows it's speaking to the right peer) its own CREDI / IDCREDI. If the CRED sizes are always the same, this exchange should be indistinguishable from an exchange done between an LwM2M client and the LwM2M backend when the client has chosen to send some more garbage bytes. (For application such as eighthalve's, it should be noted that there is probably no need for any further proof of identity inside the EAD1 plaintext: Possession of GE in combination with the suitable plaintext should suffice to open the present alternative server credentials, any secret whose possession is proven in the plaintext part would be exactly as secret as GE, as no attacker without E can obtain the plaintext.). To condense this all into a few actionable points: We should have a code point in eadlabel for "encrypted EAD" data. (We may not even have to specify how it works, that can be specified later or even be guided by the out-of-band information that needs to be present for all of this anyway). That code point either needs to be described explicitly as "MUST ignore if not supported / content not understood" for all of EDHOC from the start, or there needs to be general wording about which ead_labels are to be ignored if unprocessable. We should encourage initiators to send some random garbage there if they can afford it. (A LoRA device certainly can't, a 6lo device probably neigther, but a guard proxy establishing a connection probably can). This is not only to protect initiators that need it, but also to ensure that it is not being blocked, and that responders don't reveal whether they support it.
This has parallels to , which will take some work to pick out in detail.


Question: Authorization Data" under the new group name "Ephemeral Diffie- Hellman Over COSE (EDHOC)".  The registration procedure is "Specification Required".  The columns of the registry are Label, <del> Message, Description, and Reference, where Label is an integer and the other columns are text strings. </del> <ins> Description, and Reference, where Label is a positive integer and the other columns are text strings. </ins> 9.6.

I'm trying to understand what would need to be changed in EDHOC to support this functionality. The distinction between critical and elective EADs. This seems like a good general construct. Perhaps by designated subsets of labels, e.g. negative or even eablabel are elective. The use of a designated eablabel for encrypted EAD1 seems less general and is somewhat breaking with the mindset that one application is reserving a label and defines the associated processing. Is there a problem with specifying a particular (elective) EAD for this application and associate a policy that it is used by default, with garbage when there is nothing to send? (I couldn't see obfuscating eadlabel really achieved much in practice, but I may have missed something.)
The first, yes. As for the labels, if the application reserves a label and defines the processing, it is showing a passive attacker that it is being used; this may be undesirable. Applications should have some label behind which they can hide the fact that this application is being used; I think it is preferable if that is shared by as many applications as practical (including the "it's really just garbage" application that some hosts may want to run). Whether that requires that they also share an encryption mechanism or not, I am unsure.
NAME at the IETF Hackathon, we put together a working proof of concept for URL Is that what you mean? That's not really related to ECH, but came out of MASQUE.
NAME The three-party setup seems very useful in different settings, so there may be multiple use cases where R receives EAD1 intended for a third party and needs to know that to do with it. Currently eadlabel is filling that function. If we can assume that R by default has designated third party, or sufficient information about the third party is carried in EAD1, then eadlabel could probably be encrypted. (In principle, EAD1 could be a COSEEncrypt0 or any tagged COSE object, with information needed by R in the unprotected header.) So how do we handle the case when there are multiple candidate third parties and you want to hide both the intent and the third party identity?


Question: Authorization Data" under the new group name "Ephemeral Diffie- Hellman Over COSE (EDHOC)".  The registration procedure is "Specification Required".  The columns of the registry are Label, <del> Message, Description, and Reference, where Label is an integer and the other columns are text strings. </del> <ins> Description, and Reference, where Label is a positive integer and the other columns are text strings. </ins> 9.6.

A designated eadlabel is possible (or two, if critical / elective is baked into the label) but I don’t see how this label will be used other applications (so to acheive uncertainty about what is intended) because the co-existence of different candidate applications using EAD1 requires a method for R to distinguish between them. Maybe I'm missing something?
For the attacker to be unable to know which service the user is contacting, it would be important that an initiator receiving the credentials to the wrong service name fails in the same way has an initiator for which verification of the responder signature would fail. Otherwise, an active attacker could test if I intended to use the protected service by xoring the encrypted EAD1 with some random bytes. The responder would always see EAD1 as some random bytes and answer with the unprotected service, and then, if the initiator wanted to talk to the protected service, it will fail after decrypting the message and seeing the wrong service credentials if the initiator want to talk to the unprotected service, it will fail during the verification of the signature as the two transcript will not match. Those two failures should then be indistinguishable from the attacker point of view (even with timing attacks).
At least critical / elective EAD should be included in -15
The critical / elective logic could in principle be implemented in each application. It would be good to provide more use cases to support the case of making this a standardized feature. Clearly there is a benefit with tagging an EAD as "critical" since some operations require the information carried in the EAD to complete, e.g. authorization information from a trusted third party may be required for the Initiator to make any use of the authentication. But what EAD content is not critical? Is the following a good example for elective EAD? A service provider is allowing a variety of devices in its network to authenticate using EDHOC and grants different access rights depending on the capabilities and trustworthiness of the device. Later, the IETF specifies the EAD for remote attestation (see Appendix E). New devices which implements this EAD and appropriately attests to the attestation request carried in the EAD field get certain access which old devices doesn't get. But the old devices should still get basic access.


Question: Authorization Data" under the new group name "Ephemeral Diffie- Hellman Over COSE (EDHOC)".  The registration procedure is "Specification Required".  The columns of the registry are Label, <del> Message, Description, and Reference, where Label is an integer and the other columns are text strings. </del> <ins> Description, and Reference, where Label is a positive integer and the other columns are text strings. </ins> 9.6.

If all EAD were critical then the old device which doesn't understand the new EAD would be forced to discontinue the protocol at the arrival of the remote attestation EAD. If the EAD is elective, then both old and new devices can be supported. Question: With this example in mind, is critical / elective a property of the EAD type, or isn't it rather a boolean set by the application? I can think of another use case where remote attestation is mandatory and it doesn't make sense to define different EADs for these two use cases. (Then we are somehow back at the application specified property. But it may still make sense to have a standardized way of expressing criticality.) Thoughts?
The critical/elective property always needs to be encoded in the message (as an LSB, or as the number's sign) no matter whether criticality is the sender's choice or whether it's part of the registration. From a recent chat I think that registering one number, and then allowing it to be used in positive (elective) or negative (critical) role as by the sender's choice. Application authors would describe in which criticality/-ies it makes sense to use their number, just as they describe in which of the messages it makes sense. (The alternative is to allow registering elective and critical options independently, and that application authors who do need to give the senders a choice of using either would register a pair of options; really would work just as well). Introducing RATS data seems like a very good use case to illustrate EAD examples. (In this particular case I don't know why a sender would insist the attestation to be processed into its network joining). To rephrase the original use cases with recently published terminology, we can refer to . That reference might go with a suggestion that devices that can afford sending a few more bytes should occasionally do so in a grease-style non-critical option, or maybe in a non-critical Encrypted-EAD1 option right away. I'd welcome if ace-ake-autz already defined an EAD field for what could resemble Encrypted-Client-Hello; AIU it currently refers to an older version of EDHOC.


Question: Authorization Data" under the new group name "Ephemeral Diffie- Hellman Over COSE (EDHOC)".  The registration procedure is "Specification Required".  The columns of the registry are Label, <del> Message, Description, and Reference, where Label is an integer and the other columns are text strings. </del> <ins> Description, and Reference, where Label is a positive integer and the other columns are text strings. </ins> 9.6.

It could be updated to place LOCW and ENCID into separate EAD items, and the latter could be more generally defined as "a container for encrypted data which the responder, possibly guided by other EAD1 fields, can use to come up with a suitable IDR". (How encid is then constructed would not be a property of using that particular option, but follow from using the LOCW option). Then, there would be no need for a defined Grease field, as that ENCID field could serve the very same purpose.
Since there seems to be a case for non-critical EAD I made PR . Please review. (Yes, ace-ake-authz needs to be updated, following the closing of this issue.)
I did not read this discussion before now as it did not seem relevant for the base EDHOC protocol. The PR seems quite far from the use case described here. PR described a general critical, non-critical mechanism similar to X.509 extensions while the discussion in this issue is about an ECH type of mechanism..... PR does not seem to be the basis of a good ECH mechanism.... NAME could you have a short presentation at LAKE IETF 114? (edit: fixed Christian's github name)
I think it is clear that PR does not solve the use case outlined here. In particular, the comment from NAME above is not considered as far as I can see. But the point about critical / non-critical (eadlabel, eadvalue) appeared in this discussion and merits to be specified as a general feature.
I think it would be good with longer discussion about ECH type mechanisms in EDHOC. Might be added on later but it could also benefit from being added alrady in the base EDHOC specification. For a use case where the Initiator knows the long term key of the Responder the TLS ECH solution is a quite ugly hack that uses two different keys and an ineficient message flow. The use of a single key as discussed above is an improvement, but the use of a noise XX pattern is not optimal. If you want to design something for the use case where the Initiator knows the long term key of the Responder it makes more sense with noise IK which is used by WireGuard. If the use case where Initiator knows the long term key of the Responder is small the above approach makes sense.


Question: Authorization Data" under the new group name "Ephemeral Diffie- Hellman Over COSE (EDHOC)".  The registration procedure is "Specification Required".  The columns of the registry are Label, <del> Message, Description, and Reference, where Label is an integer and the other columns are text strings. </del> <ins> Description, and Reference, where Label is a positive integer and the other columns are text strings. </ins> 9.6.

If is is big it might make more sense to define new method(s) based on the noise IK pattern.
Could we have a design team meeting or an interim to discuss this issue?
In the use case that the Initiator gets the Responders static public key beforehand The Responder would in this case have a static DH key. The Initiator could use Static DH or a singature.
Perhaps a breakout meeting during/just before IETF 114?
Closing this since NAME agreed that the introduction of critical/non-critical EAD (PR , included in -15) in combination with an example using third party encrypted EAD (as in ace-ake-authz) resolves the issue.


Question: corresponds to the key identifier, but the encapsulated request cannot be successfully decrypted using the key. <ins> 8.4. Encapsulated requests can be copied and replayed by the oblivious proxy resource.  The design of oblivious HTTP does not assume that the oblivious proxy resource will not replay requests.  In addition, if a client sends an encapsulated request in TLS early data (see Section 8 of TLS and RFC8470), a network-based adversary might be able to cause the request to be replayed.  In both cases, the effect of a replay attack and the mitigations that might be employed are similar to TLS early data. A client or oblivious proxy resource MUST NOT automatically attempt to retry a failed request unless it receives a positive signal indicating that the request was not processed or forwarded.  The HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of RFC7540), the HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of QUIC-HTTP), or a GOAWAY frame (in either protocol version) are all sufficient signals that no processing occurred.  Connection failures or interruptions are not sufficient signals that no processing occurred. The anti-replay mechanisms described in Section 8 of TLS are generally applicable to oblivious HTTP requests.  Servers can use the encapsulated keying material as a unique key for identifying potential replays. The mechanism used in TLS for managing differences in client and server clocks cannot be used as it depends on being able to observe previous interactions.  Oblivious HTTP explicitly prevents such linkability.  Applications can still include an explicit indication of time to limit the span of time over which a server might need to track accepted requests.  Clock information could be used for client identification, so reduction in precision or obfuscation might be necessary. The considerations in RFC8470 as they relate to managing the risk of replay also apply, though there is no option to delay the processing of a request. Limiting requests to those with safe methods might not be satisfactory for some applications, particularly those that involve the submission of data to a server.  The use of idempotent methods might be of some use in managing replay risk, though it is important to recognize that different idempotent requests can be combined to be not idempotent. Idempotent actions with a narrow scope based on the value of a protected nonce could enable data submission with limited replay exposure.  A nonce might be added as an explicit part of a request, or, if the oblivious request and target resources are co-located, the encapsulated keying material can be used to produce a nonce. The server-chosen "response_nonce" field ensures that responses have unique AEAD keys and nonces even when requests are replayed. </ins> 9. Please update the "Media Types" registry at

This isn't anything that special, but this is a case where a bunch of our established defenses don't work.
The new changes LGTM. Feel free to merge assuming you're done with edits!
This means that servers need anti-replay protections, especially if they are performing non-idempotent operations.


Question: case, the advertised route is restricted to 192.0.2.0/24, rather than 0.0.0.0/0. <del> 6.2. </del> <ins> 7.2. </ins> The following example shows an IP flow forwarding setup, where a client requests to establish a forwarding tunnel to

Aligning CONNECT-IP with the changes in HTTP datagrams and CONNECT-UDP.
NAME when do you plan to merge the other PRs?
NAME I plan on merging the other PRs as soon as we have WG consensus, which (assuming no objections) should happen at the end of the month (see ) Hi folks, During today's interim call, there was strong support to proceed with the output of the Design Team. This email begins a call to confirm that consensus. As a reminder, this consists of the following changes to draft-ietf-masque-h3-datagram and draft-ietf-masque-connect-udp: URL URL Please review these changes and send your comments to the list. This consensus call will conclude on February 28. Thanks, Chris and Eric


Question: absolute index less than the Base, this representation starts with the '1' 1-bit pattern, followed by the "S" bit indicating whether the reference is into the static or dynamic table.  The 6-bit prefix <del> integer (see Section 5.1 of RFC7541) that follows is used to locate the table entry for the header name.  When S=1, the number represents </del> <ins> integer (see prefixed-integers) that follows is used to locate the table entry for the header field.  When S=1, the number represents </ins> the static table index; when S=0, the number is the relative index of the entry in the dynamic table.

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: Reference: [[this document]] <del> 9.7. </del> <ins> 9.8. </ins> The IANA Registries established in this document is defined as "Expert Review".  This section gives some general guidelines for what

(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: Reference: [[this document]] <del> 9.7. </del> <ins> 9.8. </ins> The IANA Registries established in this document is defined as "Expert Review".  This section gives some general guidelines for what

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: Reference: [[this document]] <del> 9.7. </del> <ins> 9.8. </ins> The IANA Registries established in this document is defined as "Expert Review".  This section gives some general guidelines for what

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.


Question: Reference: [[this document]] <del> 9.7. </del> <ins> 9.8. </ins> The IANA Registries established in this document is defined as "Expert Review".  This section gives some general guidelines for what

But I also sympathize with not wanting to duplicate what is already defined in another RFC (and possibly getting it wrong, as Carsten points out). Considering that there are quite a few implementers already and besides mine you have only received one other similar comment, maybe this isn't an issue for a meaningful majority. In any case, the draft has made great strides already in terms of accessibility and is in a good state now, so I don't see improvements in this area as an absolute necessity.
The two COSE constructs that are used in EHDOC, and are fairly simple. They don't use the recursive structure or embed . I think it is possible to add some additional clarifications on the structure of the COSE messages in the EHDOC draft without having to copy too much text from RFC 8152. As part of a thesis I built a proof-of-concept implementation of EDHOC in the Rust programming language available at URL The naming of the repository is due to the subject being both EDHOC and OSCORE on embedded devices, but the following refers only to the EDHOC implementation. It's based on draft-selander-ace-cose-ecdhe-14 and as such, sadly, outdated. Since it was just one part of the overall work, I only managed to implement the subset I needed, which is RPK and the signature-signature based scheme (corresponding to what draft-selander-lake-edhoc calls method 0). I also took some other shortcuts, such as not supporting auxiliary data. Fortunately, test vectors were about to be introduced just around the time I was working on it, so I've been able to successfully verify my implementation against them when John shared them with me for some preliminary testing. Since I didn't have any prior experience implementing this kind of software, I would definitely consider it more of an experiment, but it's out there and it works, in case it can be useful to anybody. I'm convinced that EDHOC will be valuable particularly in the context of OSCORE, possibly even beyond that. As for the draft itself, I would like to mention one aspect that I think could be improved from the perspective of an implementer. Part of the promise of EDHOC is that it's simple and lightweight due to reusing COSE.


Question: Reference: [[this document]] <del> 9.7. </del> <ins> 9.8. </ins> The IANA Registries established in this document is defined as "Expert Review".  This section gives some general guidelines for what

That is certainly the case, but breaks down somewhat when working on a system where no fully featured library for it is available. This was the case for me and I personally found it difficult to quickly figure out which aspects of COSE I needed to implement. 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. I know the authors are aware of this and there has been some effort to inline more information directly in the specification, which I greatly appreciate. It would be very nice to have an entirely self-contained document to work with. But I have to again point out my lack of experience in that area, it's entirely possible that this draft is in fact much better than others in this regard and I just don't know it yet. With that I would like to support the adoption and am looking forward to seeing how it develops. Kind regards, Martin


Question: A PreSharedKey proposal is invalid if any of the following is true: The "psktype" in the PreSharedKeyID struct is not set to <del> "external". </del> <ins> "resumption" and the "usage" is "reinit" or "branch". </ins> The "psk_nonce" is not of length "KDF.Nh".

Also covers the PSK part of
Interim 2022-05-26: Ready to go once merge conflicts are resolved.
The collection of structs could be less chatty. Suggest PreSharedKeys is only used once, can be inlined in GroupSecrets Use GroupContext for the internals of GroupInfo
Note: was fixed in In , we did: So only the following remain: Use GroupContext for the internals of GroupInfo
currently described at time of use. In the "Pre-Shared Keys" section, we should just specify that it must always be a fresh value of length The ReInit provisions require , but those for branching do not. Presumably these should be the same? Currently, the processing rules for PreSharedKey proposal says “MUST be external”. This seems overly restrictive; for example, it rules out the scenario in Figure 8. Suggest “MUST NOT be branch/reinit” instead.


Question: relatively short period of time, clients have an indication that the credential might have been created without the user's knowledge.  Due to the asynchronous nature of MLS, however, there may be transient <del> inconsistencies in a user's device set, so correlating users' clients </del> <ins> inconsistencies in a user's client set, so correlating users' clients </ins> across groups is more of a detection mechanism than a prevention mechanism.

Particularly in multi-device scenarios (where a user has more than one device), we should recommend that clients correlate the set of devices of each user across groups. This would make it much harder for a malicious AS to issue fake device credentials for a particular user because clients would expect the credential to appear in all groups of which the user is a member. If a device credential does not appear in all groups after a while, clients have an indication that the credential might have been created without the user's knowledge. This should however only be a recommendation since it might not be a desirable property in all scenarios. In practical terms, users might also need some time to add their new device to all of the groups, therefore a grace period might be needed. Taking the latter into account, correlating users' devices across groups is more of a detection mechanism than a prevention mechanism.
"In many uses of MLS, there are multiple MLS clients which represent a single user (for example a human user with a mobile and desktop version of an application). Often the same set of clients is represented in exactly the same list groups. In applications where this is the case, clients can compare the set of devices of each user across groups. This would make it much harder for a malicious AS to issue fake device credentials for a particular user because clients would expect the credential to appear in all groups of which the user is a member. If a device credential does not appear in all groups after some relatively short period of time, clients have an indication that the credential might have been created without the user's knowledge. As this may take some time, correlating users' devices across groups is more of a detection mechanism than a prevention mechanism."
I lightly edited NAME prose and turned it into PR .
Made a quick pass. I think we should stick with "clients" rather than "devices".