Question: any web server that is accessible to the ACME server, even if it is not accessible to the ACME client. <del> The risk of SSRF through this channel is limited by the fact that the attacker can only control the domain of the URL, not the path. Nonetheless, in order to further limit the SSRF risk, ACME server operators should ensure that validation queries can only be sent to servers on the public Internet, and not, say, web services within the server operator's internal network.  Since the attacker could make requests to these public servers himself, he can't gain anything extra through an SSRF attack on ACME aside from a layer of anonymization. </del> <ins> It might seem that the risk of SSRF through this channel is limited by the fact that the attacker can only control the domain of the URL, not the path.  However, if the attacker first sets the domain to one they control, then they can send the server an HTTP redirect (e.g., a 302 response) which will cause the server to query an arbitrary URI. In order to further limit the SSRF risk, ACME server operators should ensure that validation queries can only be sent to servers on the public Internet, and not, say, web services within the server operator's internal network.  Since the attacker could make requests to these public servers himself, he can't gain anything extra through an SSRF attack on ACME aside from a layer of anonymization. </ins> 9.5.

NAME does this look better?
LGTM, though I'd change the attacker from a "he" to a "they" on general principles.
Not a huge fan of the singular "they", but can't be bothered to rewrite around it :)
Yes, this is clearer. Thanks. Saying "will cause the server to query an arbitrary URI" is good. Technically you can even specify a non-HTTP protocol in an HTTP redirect, and this language should cover that too. (Go's net/http used by Boulder only does HTTP and HTTPS I think, but things like libcurl support a slightly insane number of protocols.) I'm not sure if the usages of "URI" vs "URL" in this section are correct, you may want to make them consistent. I never know which one to actually use. This looks good to me.


Question: 2.2.1. A standard for providing a portal URI using DHCP or Router <del> Advertisements is described in RFC7710bis.  The CAPPORT architecture expects this URI to indicate the API described in section_api. </del> <ins> Advertisements is described in RFC7710bis.  The captive portal architecture expects this URI to indicate the API described in section_api. </ins> 2.2.2.

This replaces all mentions of capport (other than document slugs) with "captive portal". Note: this change includes the title of the document.
Joel Halpern writes, We should do this.
Or erase all mentions of 'capport'


Question: The MD5 and SHA-1 hashing algorithms are steadily weakening in strength and their deprecation process should begin for their use in TLS 1.2 digital signatures.  However, this document does not <del> deprecate SHA-1 in HMAC for record protection. </del> <ins> deprecate SHA-1 in HMAC for record protection.  This document updates RFC 5246 and RFC 7525. </ins> 1. The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is specified in RFC5246.  MD5 and SHA-1 have been proven to be insecure, <del> subject to collision attacks.  RFC6151 details the security considerations, including collision attacks for MD5, published in 2011.  NIST formally deprecated use of SHA-1 in 2011 NISTSP800-131A-R2 and disallowed its use for digital signatures at the end of 2013, based on both the Wang, et. al, attack and the potential for brute-force attack.  In 2016, researchers from INRIA identified a new class of transcript collision attacks on TLS (and other protocols) that rely on efficient collision-finding algorithms on the underlying hash constructions Transcript-Collision.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates RFC5246 and RFC7525 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. </del> <ins> subject to collision attacks Wang.  In 2011, RFC6151 detailed the security considerations, including collision attacks for MD5.  NIST formally deprecated use of SHA-1 in 2011 NISTSP800-131A-R2 and disallowed its use for digital signatures at the end of 2013, based on both the Wang, et. al, attack and the potential for brute-force attack.  In 2016, researchers from INRIA identified a new class of transcript collision attacks on TLS (and other protocols) that rely on efficient collision-finding algorithms on the underlying hash constructions Transcript-Collision.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates RFC5246 and RFC7525 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </del> <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 2.

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


Question: The MD5 and SHA-1 hashing algorithms are steadily weakening in strength and their deprecation process should begin for their use in TLS 1.2 digital signatures.  However, this document does not <del> deprecate SHA-1 in HMAC for record protection. </del> <ins> deprecate SHA-1 in HMAC for record protection.  This document updates RFC 5246 and RFC 7525. </ins> 1. The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is specified in RFC5246.  MD5 and SHA-1 have been proven to be insecure, <del> subject to collision attacks.  RFC6151 details the security considerations, including collision attacks for MD5, published in 2011.  NIST formally deprecated use of SHA-1 in 2011 NISTSP800-131A-R2 and disallowed its use for digital signatures at the end of 2013, based on both the Wang, et. al, attack and the potential for brute-force attack.  In 2016, researchers from INRIA identified a new class of transcript collision attacks on TLS (and other protocols) that rely on efficient collision-finding algorithms on the underlying hash constructions Transcript-Collision.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates RFC5246 and RFC7525 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. </del> <ins> subject to collision attacks Wang.  In 2011, RFC6151 detailed the security considerations, including collision attacks for MD5.  NIST formally deprecated use of SHA-1 in 2011 NISTSP800-131A-R2 and disallowed its use for digital signatures at the end of 2013, based on both the Wang, et. al, attack and the potential for brute-force attack.  In 2016, researchers from INRIA identified a new class of transcript collision attacks on TLS (and other protocols) that rely on efficient collision-finding algorithms on the underlying hash constructions Transcript-Collision.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates RFC5246 and RFC7525 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </del> <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 2.

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


Question: Change Controller: IESG <del> 9.9. </del> <ins> 9.8.2. Type name: application Subtype name: cid-edhoc+cbor-seq </ins> <del> IANA has added the media type "application/edhoc" to the "CoAP Content-Formats" registry under the group name "Constrained RESTful Environments (CoRE) Parameters". </del> <ins> Required parameters: N/A </ins> <del> Media Type: application/edhoc </del> <ins> Optional parameters: N/A </ins> <del> Encoding: </del> <ins> Encoding considerations: binary </ins> <del> ID: TBD42 </del> <ins> Security considerations: See Section 7 of this document. </ins> <del> Reference: [[this document]] </del> <ins> Interoperability considerations: N/A Published specification: [[this document]] (this document) Applications that use this media type: To be identified Fragment identifier considerations: N/A Additional information: Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A Person & email address to contact for further information: See "Authors' Addresses" section. Intended usage: COMMON Restrictions on usage: N/A Author: See "Authors' Addresses" section. Change Controller: IESG 9.9. IANA has added the media types "application/edhoc+cbor-seq" and "application/cid-edhoc+cbor-seq" to the "CoAP Content-Formats" registry under the group name "Constrained RESTful Environments (CoRE) Parameters". </ins> 9.10.

Signed-off-by: David Navarro
NAME NAME and others: Any response to John's comment?
NAME I included John's suggestion in the PR.
Looks good to me. Other opinions?
As specified in section , the payload in some CoAP messages can be an EDHOC message prepended by either a C_x identifier or "true". The draft states: However, the payload is actually a CBOR Sequence as defined by . Thus, we could define and use a new media type "application/edhoc+cbor-seq". Note that the usage of the Content-Format option is optional.
Makes sense to me. NAME NAME others: Comments? Good that you bring up the optionality of Content-Format, we should stress that in this text. The discussion in Hackathon also reminded me about the common-option-compression which NAME presented in the May 12 interim 2021 - how to replace the Uri-Path: "/.well-known/edhoc" with a, say, integer valued CoAP option.
Makes a lot of sense to me, too.
I find this distinction good and the solution consequential, still open for comments.


Question: 1. Censorship is where an entity in a position of power - such as a <del> government, organization, or individual - supresses communication </del> <ins> government, organization, or individual - suppresses communication </ins> that it considers objectionable, harmful, sensitive, politically incorrect or inconvenient.  (While censors that engage in censorship or establish censorship regimes must do so through legal, military,

s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:


Question: Hello, with a different ephemeral key share, as the terminating server will fail to decrypt and verify the ESNI value. <del> 7.2.2. </del> <ins> 7.3.2. </ins> This design depends upon DNS as a vehicle for semi-static public key distribution.  Server operators may partition their private keys

Since OCSP is the server name, ESNI should probably enforce OCSP stapling (similar to ) or any other way of encrypted OCSP checks. Ignoring OCSP status checks entirely makes it hard to revoke a certificate, even if it's only valid for a few months.
NAME what behavior do you expect here? Would clients fail hard if server don't send stapled responses? It's good to view ESNI as part of the leaky boat problem. It plugs one hole, but not all of them. Implementations probably should do something about cleartext OCSP if they want all holes plugged.
Thank you for the changes. LGTM.


Question: 5.4. <del> frames implicitly create a stream and carry stream data.  The Type field in the frame takes the form 0b00001XXX (or the set of values from 0x08 to 0x0f) to maximize compatibility with QUIC.  However, unlike QUIC, there are only one bit used to determine the fields that are present in the frame: The FIN bit (0x01) indicates that the frame marks the end of the stream.  The final size of the stream is the sum of the length, in bytes, of all data previously sent on this stream and the length of this frame without the length of the Stream ID. </del> <ins> frames implicitly create a stream and carry stream data. The Type field in the frame is either 0x0a or 0x0b.  This uses the same frame types as a QUIC STREAM frame with the OFF bit clear and the LEN bit set.  The FIN bit (0x01) in the frame type indicates that the frame marks the end of the stream in one direction.  Stream data consists of any number of 0x0a frames followed by a terminal 0x0b frame. frames contain the following fields: The stream ID for the stream. Zero or more bytes of data for the stream.  Empty frames MUST NOT be used unless they open or close a stream; an endpoint MAY treat an empty frame that neither starts nor ends a stream as a session error. </ins> 5.5.

The definition was a little loose, so I rewrote it. We only need to use 0x0a and 0x0b, which is lucky and it lets us avoid much of the mess that QUIC has around bits in the type. I've also added definitions for the fields in the frame.


Question: This property represents the maximum Message size that an application can send. <del> 7.1.10.4. </del> <ins> 7.1.11.4. </ins> recvMsgMaxLen

There are many ways to do this, but this one mimics the "private browsing" paradigm" as I understand it.
Can you say more? I read as specifically about flushing state, not Connection Group vs. Connection issues generally. This is not literally "flushing" the state but I've update taps-interface to reflect this design while, I think, preserving the spirit of the original text.
Connection Groups used to be about state and context sharing as well as entanglement. Now it's about entanglement. We need to rename Connection Groups ("connection contexts"?) in the architecture to replace the existing "group" concept, and to retain "connection group" in the API for entanglement.
Seems like this could be 360 degrees of rotation in our thinking? (which could be OK, NEAT was written to specify both contexts and flow groups). Let's try some definitions here and see if we converge...
I think brings this back in synch again so no need to rename, possibly the last part of this section in architecture should be removed though as we do not have fine-grained control
Section 9.1 of taps-impl loosely refers to the need for an interface to "flush protocol state" to preserve anonymity, but such a capability is not in taps-interface.
I don't like this text: "Applications must have a way to flush protocol cache state if desired. This may be necessary, for example, if application-layer identifiers rotate and clients wish to avoid linkability via trackable TLS tickets or TFO cookies." Those of you who know me, would immediately see a "MUST"..."if desired." and a "may be necessary". My suggestion is that this digs too deep, and we should remove the text. I could also live with something more neutral though: Note: There are case where applications need to flush protocol cache state, for example, if application-layer identifiers rotate and a client wishes to avoid linkability of trackable TLS tickets or TFO cookies.
I'm fine to have the more neutral sentence proposed by Gorry. I don't think we should specify an interface for it but I think it's good to mention.
I agree that the best approach is to make it more neutral. The other option would be to say that this interface is implementation specific. For sure, we do not want it in the API I think.


Question: This property represents the maximum Message size that an application can send. <del> 7.1.10.4. </del> <ins> 7.1.11.4. </ins> recvMsgMaxLen

I have no opinion on Gorry's comment, but I'm a bit mystified by the "shouldn't be in the API doc" argument. Perhaps I'm not understanding the purpose of taps-interface? I thought it was a qualitative description of the controls offered to the application, which this clearly would be!
I would define taps as an interface to control network connections. So flushing state is a good thing in some scenarios for privacy but not really needed to handle network connections.
See also -- this surfaced that we have drifted on connection group versus context, which we need to fix in arch.
Martin to write a PR against API to propose a context API that would provide the intent of this functionality. Alternative is to NOP this in the API doc ("connection contexts are too implementation specific to expose in a general way" or similar)
A second alternative is a one-bit fix: a selection property that requires a given connection to be in a separate connection context (which implies a separate connection group) from other connections created in the preconnection.
A very nice approach IMO, thanks for doing thisI like this approach for the simplicity, but it still solves only half of the problem we have with connection groups vs. connection contexts. I am fine with merging this, but IMHO it does not fully Thanks NAME looks good to me now.


Question: errors.  The "instance" value MUST be the endpoint to which the request was targeted.  The problem document MUST also include a "taskid" member which contains the associated PPM task ID, encoded <del> with base64 RFC4648 (this value is always known, see task- configuration). </del> <ins> with base64 using the standard alphabet RFC4648 (this value is always known, see task-configuration). </ins> In the remainder of this document, we use the tokens in the table above to refer to error types, rather than the full URNs.  For

Section 3.1 says to include the PPM task ID in a field on the problem details JSON object, but the task ID may be any 32 byte value, and may not be representable as a Unicode string. I propose that we base64-encode the task ID here to resolve this.


Question: A QUIC packet with a short header includes a Destination Connection ID immediately following the first byte.  The short header does not include the Connection ID Lengths, Source Connection ID, or Version <del> fields.  The length of the Destination Connection ID is not specified </del> <ins> fields.  The length of the Destination Connection ID is not encoded </ins> in packets with a short header and is not constrained by this specification.

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


Question: 6. An entity in the RATS architecture includes at least one of the roles <del> defined in this document.  As a result, the entity can participate as a constituent of the RATS architecture.  Additionally, an entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles.  In these cases, interaction between these roles do not necessarily use the Internet Protocol. They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. </del> <ins> defined in this document.  An entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles. In these cases, interaction between these roles do not necessarily use the Internet Protocol.  They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. </ins> For example, an entity that both connects to a wide-area network and to a system bus is taking on both the Attester and Verifier roles.

URL Greetings! I got as far as I could with time constraints through the rest of the document. There are a few sections I'll likely go back over again as I was short on time when reviewing them, but do hope this is helpful towards improving the document. This review is from the editors revision on github that I started my review earlier int he week. Section 4.2: I find the following grouping a bit confusing: "Places that Attesting Environments can exist include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), and BIOS firmware." This has an attesting environment as a processor, an element, and as compiled code. That doesn't seem right, especially when you refer to the attesting environment as a "place". Do you mean where BIOS is executed perhaps? I would expect a TEE and maybe other components where security functions are offloaded, which is in some cases to a processor other than a TEE like a GPU (I'm not making a recommendation to do that here, just stating what is happening in ecosystems that exist). The following text is a little confusing, in particular, the last sentence: "An execution environment may not, by default, be capable of claims collection for a given Target Environment. Attesting Environments are designed specifically with claims collection in mind." If the attesting environment is a place, TEEs and other processors were not necessarily designed with claims in mind. If you can help to explain an attesting environment better, I can help to phrase it more clearly to convey the intended set of points as I think there are several. Section 4.3 Consider changing from: "By definition, the Attester role takes on the duty to create Evidence." To: "By definition, the Attester role creates Evidence." The following sentence is a run on and I think some additional information will help provide clarity. I don't think it's the role that is composed of nest environments. Current: "The fact that an Attester role is composed of environments that can be nested or staged adds complexity to the architectural layout of how an Attester can be composed and therefore has to conduct the Claims collection in order to create believable attestation Evidence." How about: "An Attester may be one or more nested or staged environments, adding complexity to the architectural structure.


Question: 6. An entity in the RATS architecture includes at least one of the roles <del> defined in this document.  As a result, the entity can participate as a constituent of the RATS architecture.  Additionally, an entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles.  In these cases, interaction between these roles do not necessarily use the Internet Protocol. They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. </del> <ins> defined in this document.  An entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles. In these cases, interaction between these roles do not necessarily use the Internet Protocol.  They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. </ins> For example, an entity that both connects to a wide-area network and to a system bus is taking on both the Attester and Verifier roles.

The unifying component is the root of trust and the nested, staged, or chained attestations produced. The nested or chained structure should include claims, collected by the attester to aid in the assurance or believability of the attestation Evidence." The following sentence should be broken into two: "This example could be extended further by, say, making the kernel become another Attesting Environment for an application as another Target Environment, resulting in a third set of Claims in the Evidence pertaining to that application." Proposed: "This example could be extended further by making the kernel become another Attesting Environment for an application as another Target Environment. This results in a third set of Claims in the Evidence pertaining to that application." How about changing the following sentence from: "Among these routers, there is only one main router that connects to the Verifier. " To: "A multi-chassis router, provides a management point and is the only one that connects to the Verifier. " For the following sentence, trying to remove the use of a word twice in a row and convey the same intent. Old: "After collecting the Evidence of other Attesters, this inside Verifier verifies them using Endorsements and Appraisal Policies (obtained the same way as any other Verifier), to generate Attestation Results." Proposed: "After collecting the Evidence of other Attesters, this inside Verifier uses Endorsements and Appraisal Policies (obtained the same way as any other Verifier) in the verification process to generate Attestation Results." I may try another pass at section 4 to improve readability. Section 5, Consider breaking this into 2 sentences, from: "This section includes some reference models, but this is not intended to be a restrictive list, and other variations may exist." To: "This section includes some reference models. This is not intended to be a restrictive list, and other variations may exist." Section 5.1 Two result words together is not necessary. Change from: "The second way in which the process may fail is when the resulting Result is examined by the Relying Party, and based upon the Appraisal Policy, the result does not pass the policy. "


Question: 6. An entity in the RATS architecture includes at least one of the roles <del> defined in this document.  As a result, the entity can participate as a constituent of the RATS architecture.  Additionally, an entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles.  In these cases, interaction between these roles do not necessarily use the Internet Protocol. They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. </del> <ins> defined in this document.  An entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles. In these cases, interaction between these roles do not necessarily use the Internet Protocol.  They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. </ins> For example, an entity that both connects to a wide-area network and to a system bus is taking on both the Attester and Verifier roles.

To: "The second way in which the process may fail is when the Result is examined by the Relying Party, and based upon the Appraisal Policy, the result does not pass the policy. " I suggest making the last paragraph the second paragraph. It's easier to read than the others and provides an introduction to the model before you begin talking about how it might fail. ** I may come back to this section to provide wording suggestions. Section 5.2 I suggest moving the last paragraph to the first in this instance. It also provides a nice high-level overview. The current paragraph 1&2 flow well together, hence this order suggestion. The third paragraph is a really long way of stating that interoperability is required. Entities must be able to create, send, receive, and process data (hence the need for a standard). It's fine, but could be shorter. Section 5.3: OLD: "One variation of the background-check model is where the Relying Party and the Verifier on the same machine, and so there is no need for a protocol between the two." Proposed: "One variation of the background-check model is where the Relying Party and the Verifier are on the same machine, performing both functions together. In this case, there is no need for a protocol between the two." I think the addition is necessary or you could scratch your head wondering why no protocol is needed. If they are separate functions on the same system, you'd need some way for the relying party to access the results of the verifier. The next sentence could benefit from being made into several. OLD: "It is also worth pointing out that the choice of model is generally up to the Relying Party, and the same device may need to create Evidence for different Relying Parties and different use cases (e.g., a network infrastructure device to gain access to the network, and then a server holding confidential data to get access to that data). As such, both models may simultaneously be in use by the same device." If the server holds confidential data, why does it need to create evidence to access the data? I'm not following the second example as written, so my proposed text may not be as intended.


Question: 6. An entity in the RATS architecture includes at least one of the roles <del> defined in this document.  As a result, the entity can participate as a constituent of the RATS architecture.  Additionally, an entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles.  In these cases, interaction between these roles do not necessarily use the Internet Protocol. They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. </del> <ins> defined in this document.  An entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles. In these cases, interaction between these roles do not necessarily use the Internet Protocol.  They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. </ins> For example, an entity that both connects to a wide-area network and to a system bus is taking on both the Attester and Verifier roles.

Proposed: "It is also worth pointing out that the choice of model is generally up to the Relying Party. The same device may need to create Evidence for different Relying Parties and/or different use cases. For instance, a network infrastructure device may attest evidence to gain access to the network or a server holding confidential data may require attestations of evidence to gain access to the data. As such, both models may simultaneously be in use by the same device." Section 6: The first 3 sentences are fine, but if you wanted to reduce it, it could be one sentence. Current: "An entity in the RATS architecture includes at least one of the roles defined in this document. As a result, the entity can participate as a constituent of the RATS architecture. Additionally, an entity can aggregate more than one role into itself. " Proposed: "An entity in the RATS architecture includes at least one [or more] of the roles defined in this document. " Or more is redundant, so that really isn't necessary to convey the same point. Then the last sentence: I'd change it a little from: "In essence, an entity that combines more than one role also creates and consumes the corresponding conceptual messages as defined in this document." To: "In essence, an entity that combines more than one role may create and consume the corresponding conceptual messages as defined in this document." It might not, it could be the verifier and relying party. Section 5: Consider changing from: "That is, it might appraise the trustworthiness of an application component, or operating system component or service, under the assumption that information provided about it by the lower-layer hypervisor or firmware is true. " To: "That is, it might appraise the trustworthiness of an application component, operating system component, or service under the assumption that information provided about it by the lower-layer hypervisor or firmware is true. " Section 7: I'd say it's really a stronger level of assurance of security rather than a stronger level of security in the following: "A stronger level of security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to hardware tampering. "


Question: 6. An entity in the RATS architecture includes at least one of the roles <del> defined in this document.  As a result, the entity can participate as a constituent of the RATS architecture.  Additionally, an entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles.  In these cases, interaction between these roles do not necessarily use the Internet Protocol. They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. </del> <ins> defined in this document.  An entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles. In these cases, interaction between these roles do not necessarily use the Internet Protocol.  They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. </ins> For example, an entity that both connects to a wide-area network and to a system bus is taking on both the Attester and Verifier roles.

Then with the following sentence, "The component that is implicitly trusted is often referred to as a Root of Trust." I think it would be worth mentioning that a hardware RoT is immutable and mutable RoTs in software are also possible, offering different levels for an assurance of trust/security. Section 9. Since ROLIE [RFC8322] has been added to SCAP2.0, it would be good to list that as an option since a lot of time and effort went into how to secure the exchange of formatted data for that protocol. Section 11. Privacy This is a good start. Remote attestation also provides a way to profile systems as well as the user behind that system. If attestation results go higher in the stack to include containers and applications, it could reveal even more about a system or user. The scope of access needs to be emphasized, including the administrators access to data (or restrictions). If there is a way to make inferences about attestations from their processing, that should be noted as well. Section 12: This will need to state an explicit requirement for transport encryption. In the introductory paragraph, the text is as follows: "Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or Appraisal Policy, needs to support end-to-end integrity protection and replay attack prevention, and often also needs to support additional security protections. For example, additional means of authentication, confidentiality, integrity, replay, denial of service and privacy protection are needed in many use cases. " Proposed: "Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or Appraisal Policy must support the security properties of confidentiality, integrity, and availability. A conveyance protocol includes the typical transport security considerations: o end-to-end encryption, o end-to-end integrity protection, o replay attack prevention, o denial of service protection, o authentication, o authorization, o fine grained access controls, and o logging in line with current threat models and zero trust architectures." Best regards, Kathleen


Question: each key/nonce pair MUST NOT be used to encrypt more than one message. <del> Keys, nonces and secrets of ratchets are derived using </del> <ins> Keys, nonces, and the secrets in ratchets are derived using </ins> DeriveAppSecret.  The context in a given call consists of the index of the sender's leaf in the ratchet tree and the current position in the ratchet.  In particular, the index of the sender's leaf in the

Just to recap the options as I understand them: a) Today: encryptedsenderdata = AEAD(senderdatakey, senderdatanonce, (groupID, epoch), senderdata) encryptedcontent = AEAD(appkey[i][j], appkey[i][j], (groupID, epoch, encryptedsenderdata), content) b) Sample sender data nonce from ciphertext (saves explicit nonce) encryptedcontent = AEAD(appkey[i][j], appnonce[i][j], (groupID, epoch), content) encryptedsenderdata = AEAD(senderdatakey, sample(encryptedcontent), (groupID, epoch, encryptedcontent), senderdata) c) Drop auth tag from content encryption (saves explicit nonce and content auth tag) encryptedcontent = Enc(appkey[i][j], appnonce[i][j], content) encryptedsenderdata = AEAD(senderdatakey, sample(encryptedcontent), (groupID, epoch, encryptedcontent), senderdata)
Earlier, we had considered a "masking" approach for sender data, much like QUIC does for . This approach would save 28 bytes of overhead (nonce + tag), but was abandoned because of uncertainty around the security of the masking approach. Since then, Bellare et al. published , which includes what is effectively a proof of the security properties of the QUIC scheme. The QUIC scheme is essentially scheme HN1 of the paper, the main difference being that QUIC encrypt not the nonce directly, but a packet number which is used to compute the nonce. Our application would be similar, since we would encrypt metadata used to encrypt the key and the nonce. Given this new analysis, is it time to bring back masking?
Fixed by


Question: 4.5.6. The literal header field without name reference representation <del> encodes a header field name and header field value as string </del> <ins> encodes a header field name and a header field value as string </ins> literals. This representation begins with the '001' three-bit pattern.  The

This was inspired by the comment by afrind at URL For each representation, uniformly use the word "representation" in the first sentence; use the word "identifies" if it's a verbatim entry; "encodes" otherwise; identify relative versus post-base indexing in the first sentence; move drawing right after first sentence; use consistent language describing binary format.


Question: .  A string is a well-formed JSONPath query if it conforms to the ABNF syntax in this document.  A well-formed JSONPath query is valid <del> if it also fulfills all semantic requirements posed by this document. </del> <ins> if it also fulfills all semantic requirements posed by this document, which are: </ins> <del> To be valid, integer numbers in the JSONPath query that are relevant to the JSONPath processing (e.g., index values and steps) MUST be within the range of exact values defined in I-JSON RFC7493, namely within the interval [-(2 </del> <ins> Integer numbers in the JSONPath query that are relevant to the JSONPath processing (e.g., index values and steps) MUST be within the range of exact values defined in I-JSON RFC7493, namely within the interval [-(2 </ins> <del> )+1, (2 </del> <ins> )+1, (2 </ins> <del> )-1]). </del> <ins> )-1]. </ins> <del> To be valid, strings on the right-hand side of the "=~" regex matching operator need to conform to I-D.draft-ietf-jsonpath-iregexp. </del> <ins> Strings on the right-hand side of the "=~" regex matching operator MUST conform to I-D.draft-ietf-jsonpath-iregexp. </ins> The well-formedness and the validity of JSONPath queries are independent of the JSON value the query is applied to; no further

I like this structure. We might come up with more validity requirements, so we may want to keep this even if =~ goes away (which is pretty much what we decided last week).


Question: The client instance request.  The client instance does not send any interaction modes to the server. <del> The AS determines that the request is been authorized, the AS grants access to the information in the form of response-token to the client instance.  Note that response-subject is not generally </del> <ins> The AS determines that the request has been authorized, the AS grants access to the resource in the form of response-token to the client instance.  Note that response-subject is not generally </ins> applicable in this use case, as there is no user involved. The client instance use-access-token to call the RS.

Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:


Question: other aspects of EKT processing.  EKT ciphers are free to use this field in any way, but they SHOULD NOT use other EKT or SRTP fields as an input.  The values of the parameters L, and T MUST be defined by <del> each EKTCipher. </del> <ins> each EKTCipher.  The cipher MUST provide integrity protection. </ins> 2.5.

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


Question: conveying the semantic requirements of DOH but may result in very poor performance for many uses cases. <ins> 7.3. Before using DOH response data for DNS resolution, the client MUST establish that the HTTP request URI is a trusted service for the DOH query.  For HTTP requests initiated by the DNS API client this trust is implicit in the selection of URI.  For HTTP server push (RFC7540 Section 8.2) extra care must be taken to ensure that the pushed URI is one that the client would have directed the same query to if the client had initiated the request.  This specification does not extend DNS resolution privileges to URIs that are not recognized by the client as trusted DNS API servers. </ins> 8. 8.1.

Describe how GET (not POST) is used with server push. This will ensure that you answer the bigger question: what do you do with a server push from an arbitrary server? I assume that this won't be privileged in any way, and only the configured DNS API server will have its answers routed to the DNS stack, but that needs to be explicit.
Server push in a request-response protocol like DNS would take a lot of designing. It isn't really needed in DNS because the server can always slap in additional answers in the Additional section of a request. I propose we close this by saying "HTTP server push is not defined for this protocol, but might be defined in a future version". If someone wants to define an EDNS0 or session-signal extension for it, that should be just fine.
HTTP already has server push, so I would prefer something closer to "this protocol does not alter the semantics of HTTP server push".
I think NAME is closer to what I'm thinking.. (though I don't really think that needs to be stated beyond other clarifications that this document just uses http in a particular manner, it does not define it.) additionally RR's don't quite address the same use case by the way as push can operate in more of a pub-sub fashion if you like where an additional RR is definitely a poll model.
Of course this protocol does not alter the semantics of server push, but what does it mean for a DNS client? In the DNS protocol, the only thing even vaguely like server-initiated information is stuff in the Additional section of an answer, and even then, there are pretty strict rules about ignoring it if it is at all smelly.
an often times misunderstood part of push is that a server pushes both a response and the request that it is responding to. (like dns, http is always a request/response pair, so if the client doesn't provide the request the server needs to). So that's what it means - its an answer to a particular question and you can cache it or not depending on whether that's a request you would have asked/trusted the peer to handle. That's pretty much the same rule for dns and traditional http clients. A client who would rather not have things pushed at them has existing protocol mechanisms to disable that (SETTINGS) which doh doesn't need to specify.


Question: conveying the semantic requirements of DOH but may result in very poor performance for many uses cases. <ins> 7.3. Before using DOH response data for DNS resolution, the client MUST establish that the HTTP request URI is a trusted service for the DOH query.  For HTTP requests initiated by the DNS API client this trust is implicit in the selection of URI.  For HTTP server push (RFC7540 Section 8.2) extra care must be taken to ensure that the pushed URI is one that the client would have directed the same query to if the client had initiated the request.  This specification does not extend DNS resolution privileges to URIs that are not recognized by the client as trusted DNS API servers. </ins> 8. 8.1.

I think all of this gets at what NAME was originally commenting on - you need to make a decision on whether or not you trust the server for the query/response being pushed (i.e is this your dns api server otherwise don't accept) before processing it.. this is already true for anything pushed via http but a sentence making it explicit is fine.


Question: 1. As detailed in IPHandling, exposing client private IP addresses by <del> default maximizes the probability of successfully creating direct peer-to-peer connection between two clients, but creates a significant surface for user fingerprinting.  IPHandling recognizes </del> <ins> default to web applications maximizes the probability of successfully creating direct peer-to-peer connections between clients, but creates a significant surface for user fingerprinting.  IPHandling recognizes </ins> this issue, but also admits that there is no current solution to this problem; implementations that choose to use Mode 3 to address the privacy concerns often suffer from failing or suboptimal connections

Also wrap long lines for #processing section.
Comments addressed, PTAL.
Will wait for NAME approval before merging.
LGTM, updated PR for line wrapping.
The changes to ICE candidate gathering are targeted to web browsers; the changes to ICE candidate processing affect all WebRTC endpoints.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private? If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
LGTM


Question: than or equal to the Base, the representation starts with the '0001' 4-bit pattern, followed by the post-base index (see post-base) of the matching header field, represented as an integer with a 4-bit prefix <del> (see Section 5.1 of RFC7541). </del> <ins> (see prefixed-integers). </ins> 4.5.4.

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: ".local" name may happen through Unicast DNS as noted in RFC6762, Section 3. <del> An ICE agent that supports mDNS candidates MUST support the situation where the hostname resolution results in more than one IP address. In this case, the ICE agent MUST take exactly one of the resolved IP addresses and ignore the others.  The ICE agent SHOULD use the first IPv6 address resolved, if one exists, or the first IPv4 address, if not. </del> <ins> An ICE agent SHOULD ignore candidates where the hostname resolution returns more than one IP address. </ins> An ICE agent MAY add additional restrictions regarding the ICE candidates it will resolve using mDNS, as this mechanism allows

PR for I considered referring to RFC6724, but that raises more questions than it answers it seems.
From Tom Pusateri: When more than one IPv4 or more than one IPv6 address is present, it seems like it would be better to first prefer an address that is on a shared network instead of always taking the first one (which doesn’t mean anything in DNS). If you want others to use the same address you should prefer the lowest one or the highest one or something sortable instead of the first one which could be different depending on hashing in a cache.
Discussed and agreement was to find a simple alternate algorithm.
Closed by PR


Question: 9. <ins> draft-ietf-core-dynlink-10 Binding methods now support both POST and PUT operations for server push. </ins> draft-ietf-core-dynlink-09 Corrections in Table 1, Table 2, Figure 2.

NAME NAME I've created a pull request to incorporate the exec binding method in the draft. This brings it in line with and also now has a reference to the draft itself. It would be great if you can quickly review the proposed text and see if you are ok with it
Now merged, after review comments received from NAME to highlight differences between the Push and Exec binding methods


Question: If the client instance can open a URL associated with an application on the end-user's device, the client instance indicates this by <del> sending the "app" field with boolean value "true".  The means by </del> <ins> including "app" in the array under the "start" key.  The means by </ins> which the client instance determines the application to open with this URL are out of scope of this specification.

The boolean value "true" is no longer used to specify supported interaction start modes.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: ef948b6b0b53f92352ec617e6074174e0a2eaa3f Inspect the deploy log: Browse the preview:


Question: packets being encrypted with per-version keys and the Handshake and later packets being encrypted with keys derived from the TLS key exchange.  Further, parameter negotiation is folded into the TLS <del> transcript and thus provides the same security guarantees as ordinary TLS negotiation.  Thus, an attacker can observe the client's transport parameters (as long as it knows the version-specific salt) </del> <ins> transcript and thus provides the same integrity guarantees as ordinary TLS negotiation.  An attacker can observe the client's transport parameters (as long as it knows the version-specific keys) </ins> but cannot observe the server's transport parameters and cannot influence parameter negotiation.

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: packets being encrypted with per-version keys and the Handshake and later packets being encrypted with keys derived from the TLS key exchange.  Further, parameter negotiation is folded into the TLS <del> transcript and thus provides the same security guarantees as ordinary TLS negotiation.  Thus, an attacker can observe the client's transport parameters (as long as it knows the version-specific salt) </del> <ins> transcript and thus provides the same integrity guarantees as ordinary TLS negotiation.  An attacker can observe the client's transport parameters (as long as it knows the version-specific keys) </ins> but cannot observe the server's transport parameters and cannot influence parameter negotiation.

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: active path, implementations SHOULD use T = 3xRTT. If an implementation has no way to obtain information regarding the <del> RTT of the active path, a value of 1s SHOULD be used. </del> <ins> RTT of the active path, T SHOULD be set to 1s. </ins> Profiles for specific deployment environments - for example, constrained networks I-D.ietf-uta-tls13-iot-profile - MAY specify a

/cc NAME Signed-off-by: Thomas Fossati
In this second paragraph, does this mean T=1s or RTT=1s ?
FMPOV: (because that refers to the default timeout of DTLS 1.2 RFC6347)


Question: any interaction modes to the server, indicating that it does not expect to interact with the RO.  The client instance can also signal which RO it requires authorization from, if known, by using <del> the request-user. </del> <ins> the request-user.  It's also possible for the AS to determine which RO needs to be contacted by the nature of what access is being requested. </ins> The AS determines that interaction is needed, but the client instance cannot interact with the RO.  The AS response with the

Update all diagrams to use AASVG for rendering in HTML.
To edit notification comments on pull requests, go to your ._


Question: aggregate shares into an aggregate result using the VDAF's "agg_shares_to_result" algorithm.  In particular, let "agg_shares" denote the ordered sequence of aggregator shares, ordered by <del> aggregator index, and let "agg_param" be the opaque aggregation parameter.  The final aggregate result is computed as follows: </del> <ins> aggregator index, let "report_count" denote the report count sent by the Leader, and let "agg_param" be the opaque aggregation parameter. The final aggregate result is computed as follows: </ins> 4.5.4.

Align with the latest VDAF draft. This requires two minor protocol changes: 02 added a value called the "publicshare" to the VDAF syntax. This is to support Poplar1 (and likely other schemes that need a similar extractability property). To accommodate this, the publicshare field has been added to the Report and ReportShare structures and appended to the AAD for input share encryption. (This may end up being useful for privacy.) 02 added the report count to the aggregate result computation. This is already passed to the Collector in the CollectResp, so we just need to update the aggregate result computation in the draft to match.
Rebased and pushed a minor update: The public share in Report and ReportStore now both have the same length prefix.
Rebased.
This will be VDAF-02 or 03, depending on when we need to cut DAP-02.
VDAF-03 is out, I will send a PR by end of week. URL


Question: 4.5.5. <del> A literal header field with post-base name reference represents a header field where the name matches the header field name of a dynamic table entry with an absolute index greater than or equal to the Base. </del> <ins> A literal header field with post-base name reference representation encodes a header field where the header field name matches the header field name of a dynamic table entry with an absolute index greater than or equal to the Base. </ins> This representation starts with the '0000' four-bit pattern.  The fifth bit is the 'N' bit as described in literal-name-reference.


Question: If the client's credentials indicate any subject name that is certified by any authority which the RD recognizes (which may be <del> the system's trust anchor store), all those subject names are </del> <ins> the system's trust anchor store), all such subject names are </ins> stored.  With CWT or JWT based credentials (as common with ACE), the Subject (sub) claim is stored as a single name, if it exists. With X.509 certificates, the Common Name (CN) and the complete

Some small mainly editorial fixes from Ben's review, to be merged soon.
From Ben's updated ballot: Good point, queued up.
From Ben's updated ballot:: → "The RD (always, but especially here) then needs to verify any lookup client's authorization before reveling this information directly (in resource lookup) or indirectly (when using it to satisfy a resource lookup search criterion)"
From follow-up on Ben's initial DISCUSS: → "regular registrations (i.e., per {{registration}})"
From follow-up on Ben's initial DISCUSS: It'd sound like abuse of semicolons to me; keeping it open to ask RFC editor for their technical writing expertise.


Question: RFC5705 defines keying material exporters for TLS in terms of the TLS PRF.  This document replaces the PRF with HKDF, thus requiring a new <del> construction.  The exporter interface remains the same, however the value is computed as: </del> <ins> construction.  The exporter interface remains the same.  If context is provided, the value is computed as: If no context is provided, the value is computed as: Note that providing no context computes the same value as providing an empty context.  As of this document's publication, no allocated exporter label is used with both modes.  Future specifications MUST NOT provide an empty context and no context with the same label and SHOULD provide a context, possibly empty, in all exporter computations. </ins> 8.

No context and empty context are now declared to be the same. Add some ALL CAPS WORDS for future specifications to deprecate no context. I used SHOULD to forbid no context because, if some protocol currently uses no context, switching it to empty context is a breaking change and probably not worth it. We just want new ones to always provide a context. This affects the rules for using exporters, so RFC 5705 is added to the list of updated documents. Closes issue .


Question: In practice, many contact channels that can be used to reach many clients do not provide strong assurances of the types noted above. <del> In designing and deploying contact-based recovery schemes, ACME servers operators will need to find an appropriate balance between using contact channels that can reach many clients and using contact- based recovery schemes that achieve an appropriate level of risk using those contact channels. </del> <ins> In designing and deploying recovery schemes, ACME servers operators will need to find an appropriate balance between using contact channels that can reach many clients and using contact-based recovery schemes that achieve an appropriate level of risk using those contact channels. </ins> 9.4.

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


Question: 8.3.1. <del> The server does not expose "RateLimit-Remaining" values, but resets the limit counter every second. </del> <ins> The server does not expose "RateLimit-Remaining" values (for example, because the underlying counters are not available).  Instead, it resets the limit counter every second. </ins> It communicates to the client the limit of 10 quota-units per second always returning the couple "RateLimit-Limit" and "RateLimit-Reset".

Improves example description
https://ietf-wg-URL The example with just RateLimit-Limit and RateLimit-Reset In it seems this is a case where the RateLimit-Reset value is not able to be used to determine how long one should wait, but is rather just a Limit definition ? Why not then just use RateLimit-Limit: 10;w=1 and omit the other two headers ? Is this to cater for the inevitable 429 to provide a RateLimit-Reset value at that point ? If that is the case I question the value of using the two headers in “successful” responses.
This example is related to an implementation that uses the "old" ratelimit field set, that do not support . We should improve the description.
:+1:


Question: Environment, then this sub-entity generates Evidence about its trustworthiness.  Therefore each sub-entity can be called an Attester.  Among these Attesters, there may be only some, which can <del> be called Lead Attesters, that have the communication functionality with the Verifier.  Other Attesters don't have this ability, but they are connected to the Lead Attesters via internal links or network </del> <ins> be called Lead Attesters, that have the ability to communicate with the Verifier.  Other Attesters don't have this ability, but they are connected to the Lead Attesters via internal links or network </ins> connections, and they are evaluated via the Lead Attester's help. For example, a carrier-grade router is a composite device consisting of a chassis and multiple slots.  The trustworthiness of the router depends on all its slots' trustworthiness.  Each slot has an Attesting Environment such as a TPM or TEE collecting the claims of <del> its boot process, then it generates Evidence from the claims to prove its trustworthiness.  Among these slots, only a main slot can communicate with the Verifier while other slots cannot.  But other slots can communicate with the main slot by the links between them inside the router.  So the main slot collects the Evidence of other slots, produces the final Evidence of the whole router and conveys the final Evidence to the Verifier.  Therefore the router is a Composite Attester, each slot is an Attester and the main slot is the Lead Attester. Another example is a multi-chassis router which is composed of multiple single carrier-grade routers.  The multi-chassis router provides higher throughput by interconnecting multiple routers and simpler management by being logically treated as one router.  Among these routers, there is only one main router that connects to the Verifier.  Other routers are only connected to the main router by the network cables, and therefore they are managed and verified via this main router.  So, in this case, the multi-chassis router is the Composite Attester, each router is an Attester and the main router is the Lead Attester. composite depicts the data that flows between the Composite Attester and Verifier for the remote attestation. </del> <ins> its boot process, after which it generates Evidence from the claims. Among these slots, only a main slot can communicate with the Verifier while other slots cannot.  But other slots can communicate with the main slot by the links between them inside the router.  So the main slot collects the Evidence of other slots, produces the final Evidence of the whole router and conveys the final Evidence to the Verifier.  Therefore the router is a Composite Attester, each slot is an Attester, and the main slot is the Lead Attester. Another example is a multi-chassis router composed of multiple single carrier-grade routers.  The multi-chassis router provides higher throughput by interconnecting multiple routers and simpler management by being logically treated as one router.  Among these routers, there is only one main router that connects to the Verifier.  Other routers are only connected to the main router by the network cables, and therefore they are managed and verified via this main router.  So, in this case, the multi-chassis router is the Composite Attester, each router is an Attester and the main router is the Lead Attester. composite depicts the conceptual data flow for a Composite Attester. </ins> In the Composite Attester, each Attester generates its own Evidence <del> by its Attesting Environments collecting the claims from its Target Environments.  The Lead Attester collects the Evidence of all other </del> <ins> by its Attesting Environment(s) collecting the claims from its Target Environment(s).  The Lead Attester collects the Evidence of all other </ins> Attesters and then generates the Evidence of the whole Composite Attester. <del> Inside the Lead Attester, there may be an optional Verifying Environment.  The Verifying Environment can verify the collected Evidence of other Attesters to evaluate their trustworthiness. Therefore, there are two situations when the Lead Attester generates the final Evidence. One situation is that the Lead Attester has no Verifying Environment. In this situation, the Lead Attester just collects the Evidence of other Attesters but doesn't verify them.  It may just string all these Evidence into a whole one, or it may reorganize these Evidence with a new structure and sign this final Evidence.  Then it conveys the final Evidence to the Verifier and the Verifier evaluates the Composite Attester's, including the Lead Attester's and other Attesters', trustworthiness. The other situation is that the Lead Attester has a Verifying Environment.  After collecting the Evidence of other Attesters, the Lead Attester verifies these Evidence by using the Endorsements and Appraisal Policies, which are got from the Verifier or some reliable parties, for evaluating these Attesters' trustworthiness.  Then the Lead Attester makes the verification results as claims which are the input to the final Evidence of the whole Composite Attester.  Then the Lead Attester conveys the final Attestation Evidence to the Verifier on behalf of the Composite Attester.  Before receiving the Endorsements and Appraisal Policies for other Attesters, to increase the security, the Lead Attester may first generate Evidence about its trustworthiness and convey this Evidence to the Verifier for evaluating. </del> <ins> The Lead Attester's Claims Collector may or may not include its own Verifier.  One situation is that the Claims Collector has no internal Verifier.  In this situation, the Claims Collecctor simply combines the various Evidences into the final Evidence that is sent off to the remote Verifier, which evaluates the Composite Attester's, including the Lead Attester's and other Attesters', trustworthiness. The other situation is that the Lead Attester's Claims Collector has an internal Verifier.  After collecting the Evidence of other Attesters, the Claims Collector verifies them using Endorsements and Appraisal Policies (obtained the same way as any other Verifier), for evaluating these Attesters' trustworthiness.  Then the Claims Collector combines the Attestation Results into the final Evidence of the whole Composite Attester which is sent off to the remote Verifier, which might treat the claims obtained from the local Attestation Results as if they were Evidence. </ins> 5.

This attempts to address the remaining feedback on PR on issues that were not fixed before it was merged. Signed-off-by: Dave Thaler
The simple word choice / grammar changes seem OK. I still don't understand the difference between a "claims collector" and a "verifier" (in the case where Attester B, C,... are signing evidence) and a "target environment" (in the case where Attester B, C, ... are not signing evidence). It seems this term isn't actually necessary. The case where Composite Attester is relying Evidence from "sub" attesters, the composite attester (aka claims collector) is relying Evidence not "collecting claims" in the sense that an attester "collects claims about a target environment". I think it is confusing to overload this terminology to also mean "rely Evidence".


Question: If the media section proto value indicates use of RTP: <del> [TODO: header extensions] </del> If the m= section is being recycled (see sec.subsequent- offers), dissociate the currently associated RtpTransceiver by setting its mid attribute to null.

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


Question: 12. <ins> changes from -27 to -28 Security policies / link confidentiality: Point out the RD's obligations that follow from such a policy. Simple registration: clarify term "regular registration" by introducing it along with the reference to Wording fix in first-come-first-remembered Wording fixes in RD definition </ins> changes from -26 to -27 In general, this addresses the points that were pointed out in


Question: The value for hpke_init_key MUST be a public key for the asymmetric encryption scheme defined by cipher_suite.  The whole structure is <del> signed using the client's identity key.  A KeyPackage object with an </del> <ins> signed using the client's signature key.  A KeyPackage object with an </ins> invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field.

The credentials we have defined at the moment only contain a single public key and no information regarding what signature scheme that keypair works with (even though the Spec actually says it should include the signature scheme as well). It would be nice, however, to support potential CredentialTypes that, similar to KeyPackages, include multiple supported signature schemes, each accompanied by a corresponding public key. The Key that should be used in any given group is then determined by the CipherSuite of the group (which includes a Signature Scheme). When choosing a KeyPackage of a new member, it has to be one that contains a Credential which supports that Signature Scheme. Note, that I'm not suggesting that this be the case in all Credentials, or even that we change the BasicCredential. I understand that it's possible to have multiple credentials per identity, but in some authentication settings it can be beneficial to have a 1-to-1 mapping between Credential and identity.
KeyPackages don't support multiple signature schemes? In what scenario is it beneficial?
Ah, right. I think that was the case in the past, but you're right, they don't. Of course it's always possible to just bundle a bunch of certificates, each supporting a different signature scheme and then treat that as your "Multi-Scheme Credential" in the grand scheme of things. However, if you end up rotating them a lot, where you have to sign them and potentially store the whole chain for a longer period of time, being able to support multiple signature schemes in only one credential means less overhead.
Credentials are stored in each group's ratchet tree though, so you're keeping a bunch of unnecessary key material in the group's tree which everyone has to store
That's fair. And it's not something you have to do if you don't want to. I'm just proposing for MLS to support that type of Credential in general.
To support hybrid PQ/standard schemes at any point in the future, allowing for multiple schemes is reasonable (in addition to the above arguments for it). Most applications probably will not use the feature, especially to start with, but providing support for just the option is not going to cause any of the problems noted.
PQ schemes can be used by switching the entire group to a new ciphersuite using those schemes.


Question: The value for hpke_init_key MUST be a public key for the asymmetric encryption scheme defined by cipher_suite.  The whole structure is <del> signed using the client's identity key.  A KeyPackage object with an </del> <ins> signed using the client's signature key.  A KeyPackage object with an </ins> invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field.

Requiring everybody in the group to store a bunch of unused key material isn't reasonable
The statement was not about PQ, but hybrid PQ/standard schemes. Those require use to two signature schemes, for which both types of keying material are used.
Then you need a ciphersuite that specifies a hybrid scheme.
It would be ideal to have a ciphersuite specifying a single hybrid scheme, but even that does not imply use of a single credential, unfortunately. In fact, hybrid schemes may rely on two separate credentials, with the ciphersuite specifying the hybrid algorithm for combining them. Since the "main" method of building a solo hybrid credential is under patent, there is also additional motivation for applications to use two.
I concur with Brendan here. To be consistent with our earlier decisions to (a) keep KeyPackages to one ciphersuite and (b) include the signature algorithm in the ciphersuite, we should keep credentials to one signature algorithm as well. Propose closing this PR without merging.
Discussed at 2020-10-06 interim, TODO: Re-add SignatureScheme enum, re-using the TLS signature schemes Clarify that the main job of a Credential is to provide a public key for verifying messages How it provides the credential might be different per credential type e.g., in BasicCredential, it's provided directly, X509Credential, have to parse the leaf certificate
LGTM with a couple nits.


Question: MUST be the exact string provided in the Location header field in response to the new-registration request that created the account. <del> The JWK representation of the original key (i.e., the client's current account key) </del> The JWK representation of the new key The client then encapsulates the key-change object in a JWS, signed

This was part of URL (see removal of oldKey from example payload), but I missed these two other spots. oldKey is fully specified by the account URL in the payload.


Question: A syntactically valid segment MUST NOT produce errors when executing the query.  This means that some operations that might be considered <del> erroneous, such as indexing beyond the end of an array, simply result in fewer nodes being selected. </del> <ins> erroneous, such as using an index lying outside the range of an array, simply result in fewer nodes being selected. </ins> Consider this example.  With the argument "{"a":[{"b":0},{"b":1},{"c":2}]}", the query "$.a[*].b" selects the

Avoid the term indexing, so we don't need to worry about whether it applies only to arrays or to arrays and objects.


Question: leveraging the security and congestion-control properties of QUIC. However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC <del> DATAGRAM frames when the application protocol running over QUIC is HTTP/3 H3.  It associates datagrams with client-initiated bidirectional streams.  Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </del> <ins> DATAGRAM frames with HTTP/3 H3 by association with HTTP requests. Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </ins> This document is structured as follows:

In Section 2 we start with the statement So let's just use that clearer description in the abstract and introduction too,


Question: 7. One goal of this design is that independent client requests are only <del> linkable by the chosen key configuration.  The Oblivious Relay and Gateway resources can link requests using the same key configuration by matching KeyConfig.key_id, or, if the Target Resource is willing to use trial decryption, a limited set of key configurations that share an identifier.  An Oblivious Relay Resource can link requests using the public key corresponding to KeyConfig.key_id or via the URI of the Oblivious Gateway Resource.  We refer to this set of information as the gateway's configuration. Whether or not targets can link requests depends on how gateway configuration information is produced and discovered by clients. Specifically, gateways can maliciously construct configurations to track individual clients. Ideally, all clients share a consistent view of the gateway configuration.  The number of different valid configurations can exponentially partition the anonymity set of clients.  For example, if there are two valid configurations, that would yield two anonymity sets consisting of clients that used one configuration and clients that used the other configuration.  If the size of each set is large enough, this may not be a significant loss of privacy in practice. Ensuring that many clients share a configuration is necessary to provide privacy for clients. </del> <ins> linkable by their content.  However, the choice of client configuration might be used to correlate requests.  A client configuration includes the Oblivious Relay Resource URI, the Oblivious Gateway key configuration (KeyConfig), and Oblivious Gateway Resource URI.  A configuration is active if clients can successfully use it for interacting with with a target. Oblivious Relay and Gateway Resources can identify when requests use the same configuration by matching "KeyConfig.key_id" or the Oblivious Gateway Resource URI.  The Oblivious Gateway Resource might use the source address of requests to correlate requests that use an Oblivious Relay Resource run by the same operator.  If the Oblivious Gateway Resource is willing to use trial decryption, requests can be further separated into smaller groupings based on the keys that are used. Each active client configuration partitions the client anonymity set. In practice, it is infeasible to reduce the number of active configurations to one.  Enabling diversity in choice of Oblivious Relay Resource naturally increases the number of active configurations.  A small number of configurations might need to be active to allow for key rotation and server maintenance. Client privacy depends on having each configuration used by many other clients.  It is critical prevent the use of unique client configurations, which might be used to track of individual clients, but it is also important to avoid creating small groupings of clients that might weaken privacy protections. </ins> A specific method for a client to acquire configurations is not included in this specification.  Applications using this design MUST <del> provide accommodations to mitigate tracking using gateway </del> <ins> provide accommodations to mitigate tracking using client </ins> configurations.  CONSISTENCY provides options for ensuring that <del> configurations are consistent between clients. </del> <ins> client configurations are consistent between clients. The content of requests or responses, if used in forming new requests, can be used to correlate requests.  This includes obvious methods of linking requests, like cookies COOKIES, but it also includes any information in either message that might affect how subsequent requests are formulated.  For example, FIELDING describes how interactions that are individually stateless can be used to build a stateful system when a client acts on the content of a response. </ins> 8.

I was just going to add something about correlating requests based on their content, but then it seemed like the text was duplicated some. Here is my attempt at making this better. I also expanded the notion of "configuration" to include the identity of the relay. That made it a little tricky - we really do want diversity of relays - but it makes more sense to talk about minimum anonymity set size rather than to imply that there can be a single configuration, because that is unrealistic.
Hi, The specification talks about State. Could I suggest that it explicitly mention 'or other user identifiable payloads.' Because things like JSON documents (e.g. a JWT) and SAML assertions are not 'cookies' but can carry information that might be user identifiable. Thoughts?
I think we've given short shrift to the way in which the content of requests can be used to link them. Perhaps some new text for Section 8...
NAME that text looks good to me Wanna toss up a PR?


Question: much previous information as possible.  EDHOC is furthermore designed to be as compact and lightweight as possible, in terms of message sizes, processing, and the ability to reuse already existing CBOR, <del> COSE, and CoAP libraries. </del> <ins> COSE, and CoAP libraries.  Like (D)TLS, authentication is the responsibility of the application, EDHOC identifies (and optionally transports) authentication credentials, and provides proof-of- possession of the private authentication key. </ins> To simplify for implementors, the use of CBOR and COSE in EDHOC is summarized in CBORandCOSE.  Test vectors including CBOR diagnostic

I think it would be good to point out early that the EDHOC protocol (just like TLS) only provides proof-of-possesion. Authentication has to be done by the application. I have seen horrible uses of TLS where the implementors believe RFC 8446 when it says it provides authentication.Added text for "Unauthenticated Operation". As pointed out by Marco, this is more general than just TOFU. "Unauthenticated operation" is the term used by TLS 1.3
I think this is ready to merge.
The selfie attack mitigation implies that an initiator is stopping the exchange if it receives its own identity. An active attacker can then use this behavior to test if an initiator identity is the same one as a responder identity. In turn, it implies that the initiator anonymity does not hold against an active attacker when this mitigation is enabled. To judge if this is an issue in practice, the following question should be answered: Are there scenarios where an identity is shared between an initiator and a receiver, but the initiator identity should still be protected? One could maybe think about the case where multiple initiators and receivers are on the same server, sometimes sharing public keys and using distinct ports, but it is expected that the initiators identities are still protected. Possible actions: mention privacy loss due to the selfie attack mitigation. update the selfie attack mitigation, by mentioning that initiators should conclude the exchange as usual, but can check at the end whether they are talking to themselves or not. remove the selfie attack mitigation. Classical selfie attacks are when there is a pre-shared key between an initiator and a receiver, and the initiator will be talking to itself while it believes to be talking to the receiver. When there are only public keys, as in EDHOC, it is unclear to me if what is currently called in the draft is indeed a selfie attack. An initiator talking to itself knows it and does not believe to be talking to some other identity. As such this is why it could be possible to either remove the mention of selfie attacks in the draft, or update it.
I and R are expected to stop the exchange it they receive any identity they do not want to talk to. This likely includes their own identity. Good point that this leaks information. I think that should be added, but I don't see that the own identity is special.