Compute a COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I- D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm of the selected cipher suite, using the encryption key K_4, the <del> initialization vector IV_4, the plaintext P, and the following parameters as input (see COSE): </del>  protected = h''

Compute a COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I- D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm of the selected cipher suite, using the encryption key K_4, the  <ins> initialization vector IV_4, the plaintext PLAINTEXT_4, and the following parameters as input (see COSE): </ins> protected = h''


iv_length - length of the initialization vector of the EDHOC AEAD algorithm <del> P = ( ? PAD, ? EAD_4 ) </del>  PAD = 1*true is padding that may be used to hide the length of the unpadded plaintext.

There has been a lot of suggestions and discussion regarding the key derivation latelely. Below is an attempt to summarize all the current suggstions that currently seems relatively likely to be done. This is not an issue in itself but I think it is good to have somewhere to discucess the complete changes to the key derivation. Suggested to permute the order of element in the TH2 sequence to be more resistant to any future collision attacks in hash functions. Exact order unclear but suggested to put the random and unpredictable GY first. Suggested to use PLAINTEXT instead of CIPHERTEXT in transcript hashes to simplify formal verification. Endpoints agree on that they received the same plaintext rather then the same cipertext.Suggested to use a salt derived from PRK in Extract to avoid usign the PRK keys directly in both Extract and ExpandSuggested to use unsigned integer instead of text string for label to save memory.Suggestion to add a final key derivation PRKout and use that in the exporter. Note that the exporter would also have uint labelsSuggestion to base Key-Update on Expand instead of extract. The label would need IANA registration. hashlength is a new variable that the implementation needs to keep track of. Should considered whether using Exporter for KeyUpdate has any disadvantages. Suggested that more info on how an application protocol is supposed to use KeyUpdate and Exporter together is needed.The EDHOC internal key derivations (i.e., not using the Exporter) would then be something like below. The exact labels should be discussed. Note that that only some of the derivations actually need a label to avoid collisionIncluding KeyUpdate, the IANA registered exporter labels could be:
Looks good. I had different naming in mind of the salts: PRK3e2m = Extract( SALT3e2m, GRX ) PRK3m = Extract( SALT3m, GIY ) where SALT3e2m = EDHOC-KDF( PRK2e, TH2, 0, h'', hashlength ) SALT3m = EDHOC-KDF( PRK3e2m, TH3, 0, h'', hashlength ) With this the salts are named by its use rather than from what key they are derived.
The labels was just to illustrate the fact that they don't need to be separate. I think it is still better to just use 0-7. That makes it very easy for the reader to see that there are no collisions.
NAME Was this a comment on my proposed names of salts, or a separate comment? (I agree labels 0-7 is good.)
It was a separate comments. Your suggestion for salt naming is fine with me. Some other non-technical naming things that a hidden in my summary above I think keylength should use different terms in the derivation of K4 and OSCORE Master Secret. The current naming gives the idea that they are the same. I think the contexts in the MAC2 and MAC3 derivations should be given names. Should consider collection all the EDHOC-KDF derivations in a single place.
Might want to derive: K4 = EDHOC-KDF( PRK3m, TH4, 0, h'', keylength ) IV4 = EDHOC-KDF( PRK3m, TH4, 0, h'', ivlength ) to avoid that the applicaiton gets K4 and IV4. Another alternative is to use K4 = EDHOC-Exporter( 7, h'', keylength ) IV4 = EDHOC-Exporter( 8, h'', ivlength ) and forbid the application to use the labels for K4 and IV4
Editorial; should be: K4 = EDHOC-KDF( PRK3m, TH4, 1, h'', keylength ) IV4 = EDHOC-KDF( PRK3m, TH4, 2, h'', ivlength ) or, if we want all KDF labels distinct: K4 = EDHOC-KDF( PRK3m, TH4, 8, h'', keylength ) IV4 = EDHOC-KDF( PRK3m, TH4, 9, h'', ivlength ) Alternatively, application access to Exporter only allows uint with: K4 = EDHOC-Exporter( -1, h'', keylength ) IV4 = EDHOC-Exporter( -2, h'', ivlength )
Trying to compile the suggestions. These have a PR: Suggested to permute the order of element in the TH2 sequence … Suggested to use PLAINTEXT instead of CIPHERTEXT in transcript hashes … Suggestion to add a final key derivation PRKout and use that in the exporter The following needs to be addressed: Suggested to use a salt derived from PRK in Extract define salt derive salt Suggested to use unsigned integer instead of text string for label to save memory suggestion to base Key-Update on Expand consider whether using Exporter for KeyUpdate has any disadvantages. more info on how an application protocol is supposed to use KeyUpdate and Exporter together distinguish keylength in K3/K_4 and OSCORE Master Secret define contexts explicitly table of KDF derivations
Trying to put things together. Let's call this variant A, part 1. where and (edit: depending on method) New salts to avoid double use of PRK, named by its use. Same construction for K4/IV4 as K3/IV3, motivating the renaming of 3m in as 4e3m. The label in the KDF, third argument, is an uint, all distinct for simplicity.
Variant A, part 2: Distinct "transcript hash" in KeyUpdate and Exporter. Exporter does not give access to EDHOC internal keys. OSCORE key length separate from key_length. Edit: Not clear that 'context' is needed in the EDHOC-Exporter. Also, to be strict in labelling we could continue enumeration. Here is variant B, part 2 (B.1 = A.1):
Variant C.2 (C.1 = A.1): (edited:) Same as B.2 but with different labels. With variant C we have essentially: the internal KDF labels with current list: 0, ..., 9; and the IANA EDHOC Exporter Registry with current list: 0, 1.
NAME NAME NAME and all: Any implementation considerations or other comments on variant C above? We'll start with the PR(s) soon.
The last posts here are confusing.... I don't agree. These are separate. We should definitly not try to keep them separate. I.e. it should be Master Secret = EDHOC-Exporter( 0, h'', oscorekeylength ) Master Salt = EDHOC-Exporter( 1, h'', oscoresaltlength )
The above looks good to me with the following not so interesting options. order of the 0-9 labels use 10 or 0 label for Key-Update order of the h'00' and h'01' "transcripts"
I think we should maybe merge the "context" and "transcript hash" inputs. This simplifies things and avoids using h'00' and h''01' as "transcript hashes.
Alternatively
The latest version of the summary URL looks good.
Overview of main changes needed: Merge Rename PRK3m as PRK4e3m Section 4.1 update PRK definitions move section PRKout to 4.2 Section 4.2 Update EDHOC-KDF and info definition Update derivations Include derivations of salts and K4 / IV4 List EDHOC-KDF derivations with labels 0-9 Section 4.3 Update EDHOC-Exporter (use label 10 instead of 11) Remove derivation of K4 / IV4 Section 4.4 Update EDHOC-KeyUpdate (use label 11 instead of 10) Section 5.3.2 Define context2 Section 5.4.2 Define context3 Section 9.1 Update EDHOC Exporter labels Appendix A.1 Update Master Secret/Salt derivation
Additional updates: As noted in previous comment, a proposal to interchange labels 10 and 11 to enumerate labels in the order they appear in the specification. (Other proposal for assignment of integer labels is welcome.) Should we align / adapt definition of contextx and externalaad? Currently (for message2 and similar for message3): externalaad = > context2 = > Edit: Seems to be favourable to at least align this blobs, so changed context2 to > and similar for context_3, in 5464707a
PRKexporter is a key which we only introduce for simple distinction between different KDF applications. Perhaps an overkill? May open up for unnecessary discussion about properties of that key. Here is another variant: Edit: As commented before, Marco thinks a separate PRKExporter is preferred; less error prone etc.
Most old comments are now addressed, and there are quite a few changes, so it is a good time to merge PR . Remaining points: derivation of K4/ IV4 and text about key confirmation. Not clear if there is any difference in practice between K4 /IV4 being derived from PRK4e3m or PRKout, but the current text about explicit key confirmation is not valid in the former case. May alternatively tune down the key confirmation terminology. Suggested to make clearer distinction between key derivation for EDHOC processing, resulting in PRKout, and key derivation for application, i.e. making use of PRKout in EDHOC-Exporter and EDHOC-KeyUpdate. More guidance on the latter is also proposed.
Tried to address the remaining points in the previous comment with the latest two commits: 5d675ac and 95e35bb. More guidance on KeyUpdate may still be needed. Other points?
NAME What more guidance is needed on KeyUpdate?
Was a request from someone. Might be hard to understand how to use it. E.g. that you should alternate key update and exporter Exporter Key Update Exporter Key Update Exporter ...
Another guidance needed is how to manage overwrite of PRKout pending confirmation of the derived key from the other endpoint. When the Initiator is updating PRKout it needs both old and new derived keys to be able to communicate securely in lock-step the change to the new key.
Perhaps good to remark that the entire application contexts (including e.g. sequence numbers) need to be maintained before a transition is made.
see instead. The current discussion has very little to do with

iv_length - length of the initialization vector of the EDHOC AEAD algorithm  <ins> PLAINTEXT_4 = ( ? PAD, ? EAD_4 ) </ins> PAD = 1*true is padding that may be used to hide the length of the unpadded plaintext.


typically that which is not possible to infer from routing information in the lower layers.  Compared to SIGMA, EDHOC adds an explicit method type and expands the message authentication coverage to additional elements such as algorithms, external authorization data, and previous plaintext

Further security considerations about how message content is protected against manipulation. Perhaps something like this: "Manipulations of message1 may not be detected at reception since there is no MAC but, since message1 is included in TH2, if I and R disagree on message1 then subsequent PRKs and MACs will be different. Manipulations of other messages are detected at reception through the MACs, except for manipulation of the encrypted padding of message2, since PAD2 is not integrity protected."
I made a PR for this
I merged to prepare for submission on -15. is just a simple clarification.
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. >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. The selfie attack mitigation is intended for Trust On First Use (TOFU) use cases, where there is no authentication in the initial setup. I don't think an initiator talking to itself in a TOFU use case would not know it except if they checked R's public key. Do you some better suggestion than "Selfie attack". I agree that it is not perfect. "Selfie attacks" has in older papers been called reflection attacks, but the term reflection attacks has also been used for very different attacks. One option is to not give the attack any name and instead just describe the attack.
I think I like to not give any name, as it does not perfectly match the classical definition. Here, the property which is violated is "If an EDHOC exchange is completed, two distinct identities/computers/agents were active". Which is different to violating the authentication of the protocol as is the case in classical selfie attacks. Good point. So what we are talking about in this issue is a slightly different privacy leak, which happens when the set of parties you are willing to talk to is equal to all responders minus yourself. To be more concrete, let me try to put it in a kind of drafty formal description that could replace the existing formulation. First the existing formulation: Now a possible replacement:
Thanks for the input! This issue is related to the TOFU use case which is still to be detailed (Appendix D.5). We probably should wait with the update until we have progressed that.
Relates to
I made PR for this issue. This is also related to PR and PR . The suggested text in is largely based on the suggested text above but I made some changes. I did not think this fitted well with the rest of the draft. The sentence was also not really needed. This is only true in the case where the set of identifiers is a small finite set. In the general case the set of identifiers the Initiator is not willing to communicate with is infinite. I suggest to add the following recommendation for TOFU To not leak any long-term identifiers, it is recommended to use a freshly generated authentication key as identity in each initial TOFU exchange.
I merged the PR to master. Keeping the issue open for a while.

typically that which is not possible to infer from routing information in the lower layers. <ins> EDHOC messages might change in transit due to a noisy channel or through modification by an attacker.  Changes in message_1 and message_2 (except PAD_2) are detected when verifying Signature_or_MAC_2.  Changes to PAD_2 and message_3 are detected when verifying CIPHERTEXT_3.  Changes to message_4 are detected when verifying CIPHERTEXT_4. </ins> Compared to SIGMA, EDHOC adds an explicit method type and expands the message authentication coverage to additional elements such as algorithms, external authorization data, and previous plaintext


4.1.3. <del> The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf, is the only secret key shared between Initiator and Responder that needs to be stored after a successful EDHOC exchange, see m3.  Keys for applications are derived from PRK_out, see exporter. </del>  4.2.

Should be checked for conflicts with
I think fixing the comments above resolves conflict with , so can then be replaced by this.
This proposal for update in the key derivation description also addresses the clarifications requested in , thus replacing . We merge this to include it in -15 and enable further reviews.
This is not correct. How to derive and store PRKexporter is completely up to the implementation. One can derive PRKexporter everytime Exporter is called. This make it look like PRKout is overwritten. This should be formulated with and like TLS 1.3 or with and or something. How long to save the old keying material (PRKout, PRK_Exported, any derived keys) is likely up to the application. The importand thing is that they need to be deleted to give FS.
There was a request from someone that more guidance on the use of KeyUpdate should be expanded. Maybe not clear how you are supposed to alternate KeyUpdate and Exporter to get FS.
As you are considering making the KeyUpdate more detailed, I have a general design question. Are there use cases where one would expect Post-Compromise Security? That is, if one of the participant's PRK_out is compromised, a successful KeyUpdate mechanism between the two honest parties would heal them and lock out the attacker That is typically what is met by the double ratchet from the Signal app. The classical way to achieve that is roughly to have each party send out for the update fresh DH ephemeral shares, and add the corresponding DH secret inside the key derivation. (it would of course require more care than that in the details)
I think part of the plan is to make it less detailed and leave some stuff to the implementation/application :) The current KeyUpdate mechanism only gives forward secrecy. If you exchange some nonces and use them as a context you might get protection against an attacker is not monitoring all your traffic. I think details of this should be specified outside of EDHOC like in the OSCORE KeyUpdate draft in the CORE WG. The double ratchet was discussed in LAKE WG at an earlier point. The conclusion was that it added to much complexity to specify that as part of EDHOC. To get this kind of security an application has to rerun EDHOC frequently (like TLS 1.3). Signal uses the Diffie-Hellman ratchet very often which makes it understandable to have on optimized Diffie-Hellman ratchet post-handshake. Contrained use cases of EDHOC can not do Diffie-Hellman as often as Signal so it was determined that requiring rerun of the full EDHOC was the best tradeoff. Should the EDHOC specification say more about the benefits of frequently rerunning Diffie-Hellman? I don't remember how much it says. I recently wrote a paragraph about this that was accepted to RFC8446bis.
This is not correct. PRKout does not need to be stored. An implementation can derive the application keys directly and never store PRKout. An implementation can also store PRK_exporter if they don't use EDHOC-KeyUpdate.
This is not enough. You need to be sure that the old key is not needed more.
I merged which addresses some points raised in this issue. Please review and comment if there is anything missing.
No comments received, so I assume this is fine. (KeyUpdate is now in an appendix.)

4.1.3.  <ins> The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is the output of a successful EDHOC exchange.  Keys for applications are derived from PRK_out, see exporter.  An application using EDHOC- KeyUpdate needs to store PRK_out.  If EDHOC-KeyUpdate is not used, an application only needs to store PRK_out or PRK_exporter as long as EDHOC-Exporter is used.  (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a TEE, see impl-cons). </ins> 4.2.


PRK_exporter is derived from PRK_out: where hash_length denotes the output size in bytes of the EDHOC hash <del> algorithm of the selected cipher suite. PRK_exporter MUST be derived anew from PRK_out if EDHOC-KeyUpdate is used, see keyupdate. </del>  The (label, context) pair used in EDHOC-Exporter must be unique, i.e., a (label, context) MUST NOT be used for two different purposes.

PRK_exporter is derived from PRK_out: where hash_length denotes the output size in bytes of the EDHOC hash  <ins> algorithm of the selected cipher suite.  Note that PRK_exporter changes every time EDHOC-KeyUpdate is used, see keyupdate. </ins> The (label, context) pair used in EDHOC-Exporter must be unique, i.e., a (label, context) MUST NOT be used for two different purposes.


4.2.2. To provide forward secrecy in an even more efficient way than re- <del> running EDHOC, EDHOC provides the function EDHOC-KeyUpdate.  When EDHOC-KeyUpdate is called, the old PRK_out is deleted and the new PRK_out is calculated as a "hash" of the old key using the Expand function as illustrated by the following pseudocode: </del>  where hash_length denotes the output size in bytes of the EDHOC hash algorithm of the selected cipher suite.

4.2.2. To provide forward secrecy in an even more efficient way than re-  <ins> running EDHOC, EDHOC provides the optional function EDHOC-KeyUpdate. When EDHOC-KeyUpdate is called, a new PRK_out is calculated as a "hash" of the old PRK_out using the Expand function as illustrated by the following pseudocode.  The change of PRK_out causes a change to PRK_exporter and derived keys using EDHOC-Exporter. </ins> where hash_length denotes the output size in bytes of the EDHOC hash algorithm of the selected cipher suite.


The EDHOC-KeyUpdate takes a context as input to enable binding of the updated PRK_out to some event that triggered the keyUpdate.  The Initiator and the Responder need to agree on the context, which can, <del> e.g., be a counter or a pseudorandom number such as a hash.  The Initiator and the Responder also need to cache the old PRK_out until it has verfied that the other endpoint has the correct new PRK_out. </del>  I-D.ietf-core-oscore-key-update describes key update for OSCORE using EDHOC-KeyUpdate.

The EDHOC-KeyUpdate takes a context as input to enable binding of the updated PRK_out to some event that triggered the keyUpdate.  The Initiator and the Responder need to agree on the context, which can,  <ins> e.g., be a counter or a pseudorandom number such as a hash.  To provide forward secrecy the old PRK_out and derived keys must be deleted as soon as they are not needed.  When to delete the old keys and how to verify that they are not needed is up to the application. </ins> I-D.ietf-core-oscore-key-update describes key update for OSCORE using EDHOC-KeyUpdate.


identifiers from EDHOC SHOULD provide mechanisms to update the connection identifier and MAY provide mechanisms to issue several simultaneously active connection identifiers.  See RFC9000 for a non- <del> constrained example of such mechanisms.  Connection identifiers SHOULD be unpredictable.  Using the same identifier several times is not a problem as long as it is chosen randomly.  Connection identity privacy mechanisms are only useful when there are not fixed identifiers such as IP address or MAC address in the lower layers. </del>  8.6.

Suggestion to clarify and maybe give example of randomness and unpredictability. The SHOULD should probably be removed. Unclear if 1 byte identifiers can ever by unpredictable.
Closing this as approved by Marco.
Looks good to me. NAME ?

identifiers from EDHOC SHOULD provide mechanisms to update the connection identifier and MAY provide mechanisms to issue several simultaneously active connection identifiers.  See RFC9000 for a non-  <ins> constrained example of such mechanisms.  Connection identifiers can e.g., be chosen randomly among the set of unused 1-byte connection identifiers.  Connection identity privacy mechanisms are only useful when there are not fixed identifiers such as IP address or MAC address in the lower layers. </ins> 8.6.


With static Diffie-Hellman key authentication, the authenticating endpoint can deny having participated in the protocol. <del> Two earlier versions of EDHOC have been formally analyzed Norrman20 Bruni18 and the specification has been updated based on the analysis. </del>  8.2.

Hi all, Our previous formal analysis on draft 12 and 14 lead to a publication at USENIX 23 available here URL As the two other previous formal analysis were cited in the draft, I'm proposing to add next to them our new one with this PR. As a side remark, our models are here (URL), and we are trying to update everything according to draft 17 with a new overall pass. It might be tight for IETF115, but we are trying our best! And anyway, it should only be positive results by now ;)
NAME Thanks! Great that you follow up with the latest version. The latest relevant changes are probably in -16 and only adds things to the key derivation (some of which was proposed by you :-).
Thanks for the pointer! Though, the biggest issue is not so much updating the model of the protocol, but rather making a new full pass on the security claims and new appendices, trying to have a clear systematized link between claims from the draft and what we check in the model.
NAME let's check if there are some other papers missing and what we want to say about them.
We should at least add references to work by ETH and ENS. Let's merge this as a starting point and continue discussion in .
Given the various security analyses EDHOC has seen and their insights being discussed in Section 8, would it make sense to add informative references to those (as done, e.g., for TLS 1.3, RFC 8446 Appendix E)? URL
Seems like a good idea to me
Related to
This was discussed on the IETF 116 LAKE WG meeting, and in absence of volunteers to draft such an appendix we decided to start with adding references. We may want to go somewhere in between a whole appendix and a sentence, and expand with a paragraph about each reference. We still need someone to draft that paragraph for the different references and would like to conclude on this fairly soon. We start by merging now.
Closing since is merged. Hi all, While we do not have any explicit comments on the document, we thought it is maybe still worthwhile to share the following analysis confirmation. We updated our computational analysis of the SIG-SIG mode, of which Marc presented an earlier version at IETF 114, to draft 17. We could confirm that with some of the later cryptographic suggestions (PR , ) included, EDHOC SIG-SIG achieves key exchange security (key secrecy and explicit authentication) in a strong model capturing potentially colliding credential identifiers, assuming, among others, an "exclusive ownership" property of the signature scheme (established for Ed25519, conjectured for the way ECDSA is used in EDHOC SIG-SIG). Our updated analysis is not publicly available yet at this point. Let us know if a public reference would be helpful for the draft RFC; we can also share the document individually upon request. The last point actually maybe does lead to a comment on the document: Given the various security analyses EDHOC has seen and their insights being discussed in Section 8, would it make sense to add informative references to those (as done, e.g., for TLS 1.3, RFC 8446 Appendix E)? Kind regards, Felix Günther (with Marc Ilunga)

With static Diffie-Hellman key authentication, the authenticating endpoint can deny having participated in the protocol.  <ins> Three earlier versions of EDHOC have been formally analyzed Jacomme23 Norrman20 Bruni18 and the specification has been updated based on the analysis. </ins> 8.2.


member impersonate another group member, but a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways.  A naive sharing of PSKs, even assuming only <del> honest but curious participants know the key, does not enforce any of these properties, bar one.  Endpoint Identity Protection holds vacuously, because the client and server do not use certificates in PSK mode.  (This is not true with use of the "tls_cert_with_extern_psk" extension I-D.ietf-tls-tls13-cert-with- extern-psk.) </del>  In the following sub-sections, we list attacks that demonstrate violations of these properties when the fundamental PSK assumption <del> does not hold.  This list is not exhaustive, but merely highlights a number of potential pitfalls. </del>  3.1.1.

Changes to comments from Russ Housley on 03-Mar-2020
Section 3.1.1: The text says: C responds with to A. I think that C responds with a ServerHello to A. Section 3.1.2: The text says: A sends a ClientHello to B, without including a key share. It would be helpful to say "without including a key share extension." Section 3.1.3: I think a bit more explanation is needed here. Nonces can make the keys different, why doesn't the nonce from the uncompromised party help in this example? Section 4: I would like to see a bit more context here. I agree with the recommendations for the intended environment, but they are overkill in the environment suggested by draft-ietf-tls-tls13-cert-with-extern-psk. In fact, they are overkill if (EC)DH is combined with the PSK at all. So, maybe we just need to say that the PSK is not combined with a pairwise key that these rules apply.
Fixed by .
LGTM -- thanks, Russ!

member impersonate another group member, but a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways.  A naive sharing of PSKs, even assuming only  <ins> honest but curious participants know the key, can violate all these properties, bar one.  Endpoint Identity Protection holds vacuously, because the client and server do not use certificates in PSK mode. (This is not true with use of the "tls_cert_with_extern_psk" extension I-D.ietf-tls-tls13-cert-with-extern-psk.) </ins> In the following sub-sections, we list attacks that demonstrate violations of these properties when the fundamental PSK assumption  <ins> does not hold. </ins> 3.1.1.


The attacker intercepts the message and redirects it to "C". <del> "C" responds with to "A". </del>  "A" sends a "Finished" message to "B".  "A" has completed the handshake, ostensibly with "B".

The attacker intercepts the message and redirects it to "C".  <ins> "C" responds with a "ServerHello" to "A". </ins> "A" sends a "Finished" message to "B".  "A" has completed the handshake, ostensibly with "B".


Let the group of peers who know the key be "A", "B", and "C".  The attack proceeds as follows: <del> "A" sends a "ClientHello" to "B", without including a key share. </del>  The handshake completes as expected.

Let the group of peers who know the key be "A", "B", and "C".  The attack proceeds as follows:  <ins> "A" sends a "ClientHello" to "B", without including a key share extension. </ins> The handshake completes as expected.


properties outlined above.  The attack violates the same session keys property, as "A" and "B" have each completed a session, ostensibly with each other, and yet do not agree on the session key.  If "A" <del> does not send a key share, then the attacker can have a session with "A" and a separate session with "B", where both sessions have the same key.  This violates the uniqueness of session keys property.  In the case of KCI resistance, where we assume the attacker has compromised "A", the attacker can successfully impersonate "B" to "A" using this pattern. </del>  4. <del> Given the desired security goals from sec-properties, applications which make use of external PSKs MUST adhere to the following requirements: </del>  Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a

properties outlined above.  The attack violates the same session keys property, as "A" and "B" have each completed a session, ostensibly with each other, and yet do not agree on the session key.  If "A"  <ins> does not send a key share extension, then the attacker can have a session with "A" and a separate session with "B", where both sessions have the same key.  Since the attacker has knowledge of all of the messages and their content, the nonce in the handshake does not prevent the attacker from computing the full key schedule.  This violates the uniqueness of session keys property.  In the case of KCI resistance, where we assume the attacker has compromised "A", the attacker can successfully impersonate "B" to "A" using this pattern. </ins> 4.  <ins> To achieve the security goals from sec-properties when the external PSK will not be combined with a pairwise secret value, applications MUST use external PSKs that adhere to the following requirements: </ins> Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a


Each PSK MUST be at least 128-bits long. <del> Each PSK SHOULD be seeded from a source with at least 128-bits of entropy. </del> 5. PSK privacy properties are orthogonal to security properties

Each PSK MUST be at least 128-bits long.  5. PSK privacy properties are orthogonal to security properties


appearing in cleartext in a ClientHello.  As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire.  Applications should take precautions when <del> using external PSKs if these risks are a concern. </del>  In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can

appearing in cleartext in a ClientHello.  As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire.  Applications should take precautions when  <ins> using external PSKs if these risks. </ins> In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can


First Use (TOFU) approach with a device completely unprotected before the first login did take place).  Many devices have very limited UI.  For example, they may only have a numeric keypad or <del> perhaps an interface with even fewer buttons.  When the TOFU approach is not suitable, entering the key may require typing it on a very constrained UI.  Moreover, PSK production lacks guidance unlike user passwords. </del>  Some devices are provisioned PSKs via an out-of-band, cloud-based syncing protocol.

First Use (TOFU) approach with a device completely unprotected before the first login did take place).  Many devices have very limited UI.  For example, they may only have a numeric keypad or  <ins> even less number of buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI.  Moreover, PSK production lacks guidance unlike user passwords. </ins> Some devices are provisioned PSKs via an out-of-band, cloud-based syncing protocol.


1. <del> This document provides usage guidance for external Pre-Shared Keys (PSKs) in TLS.  It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document also discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  It provides advice for applications in various use cases to help meet these assumptions. </del>  The guidance provided in this document is applicable across TLS RFC8446, DTLS I-D.ietf-tls-dtls13, and Constrained TLS I-D.ietf-tls-

The comment about how there are no guidelines about PSKs like there are about generating passwords seemed like a statement of the motivation for this draft, so I moved it to the introduction. (I was going to add a reference for the statement, but I couldn't figure out how to get the citation to compile correctly. This was the document I was going to cite, in case you think it needs it: URL)

1.  <ins> There are many resources that provide guidance for password generation and verification aimed towards improving security. However, there is no such equivalent for external Pre-Shared Keys (PSKs) in TLS.  This document aims to reduce that gap.  It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks. This document also discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  It provides advice for applications in various use cases to help meet these assumptions. </ins> The guidance provided in this document is applicable across TLS RFC8446, DTLS I-D.ietf-tls-dtls13, and Constrained TLS I-D.ietf-tls-


6. <del> Pre-shared Key (PSK) ciphersuites were first specified for TLS in 2005.  Now, PSK is an integral part of the TLS version 1.3 specification RFC8446.  TLS 1.3 also uses PSKs for session resumption.  It distinguishes these resumption PSKs from external PSKs which have been provisioned out-of-band (OOB).  Below, we list some example use-cases where pair-wise external PSKs (i.e., external PSKs that are shared between only one server and one client) have been used for authentication in TLS. </del>  Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known

6.  <ins> PSK ciphersuites were first specified for TLS in 2005.  Now, PSKs are an integral part of the TLS version 1.3 specification RFC8446.  TLS 1.3 also uses PSKs for session resumption.  It distinguishes these resumption PSKs from external PSKs which have been provisioned out- of-band (OOB).  Below, we list some example use-cases where pair-wise external PSKs (i.e., external PSKs that are shared between only one server and one client) have been used for authentication in TLS. </ins> Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known


limited UI.  For example, they may only have a numeric keypad or even less number of buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a <del> constrained UI.  Moreover, PSK production lacks guidance unlike user passwords. </del>  Some devices provision PSKs via an out-of-band, cloud-based syncing protocol.

limited UI.  For example, they may only have a numeric keypad or even less number of buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a  <ins> constrained UI. </ins> Some devices provision PSKs via an out-of-band, cloud-based syncing protocol.


Keys (PSKs) in Transport Layer Security (TLS) 1.3 RFC8446.  This guidance also applies to Datagram TLS (DTLS) 1.3 I-D.ietf-tls-dtls13 and Compact TLS 1.3 I-D.ietf-tls-ctls.  For readability, this <del> document uses the term TLS to refer to all such versions.  External PSKs are symmetric secret keys provided to the TLS protocol </del>  implementation as external inputs.  External PSKs are provisioned <del> out-of-band.  This document lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  This document also provides advice for applications in various use cases to help meet these assumptions. </del>  There are many resources that provide guidance for password generation and verification aimed towards improving security.

More = better. There are a few other places that this treatment might be applied elsewhere if the editors feel that way inclined. This seemed to be the most important.
I'll do a pass for other obvious paragraphs that can be split up.

Keys (PSKs) in Transport Layer Security (TLS) 1.3 RFC8446.  This guidance also applies to Datagram TLS (DTLS) 1.3 I-D.ietf-tls-dtls13 and Compact TLS 1.3 I-D.ietf-tls-ctls.  For readability, this  <ins> document uses the term TLS to refer to all such versions. External PSKs are symmetric secret keys provided to the TLS protocol </ins> implementation as external inputs.  External PSKs are provisioned  <ins> out-of-band. This document lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  This document also provides advice for applications in various use cases to help meet these assumptions. </ins> There are many resources that provide guidance for password generation and verification aimed towards improving security.


This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. <del> This document lists TLS security properties provided by PSKs under certain assumptions, and then demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases and provisioning processes.  This document provides advice for applications to help meet these assumptions.  This document also lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. </del>  1.

Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.

This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.  <ins> It lists TLS security properties provided by PSKs under certain assumptions, and then demonstrates how violations of these assumptions lead to attacks.  Advice for applications to help meet these assumptions is provided.  It also discusses PSK use cases and provisioning processes.  Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. </ins> 1.


If PSK is not combined with fresh ephemeral key exchange, then compromise of any group member allows the attacker to passively <del> read (and actively modify) all traffic. </del>  Additionally, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as described

If PSK is not combined with fresh ephemeral key exchange, then compromise of any group member allows the attacker to passively  <ins> read (and actively modify) all traffic, including past traffic. </ins> Additionally, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as described


value and the receiving member's known identity.  See Selfie for details. <del> To illustrate the rerouting attack, consider the group of peers who know the PSK be "A", "B", and "C".  The attack proceeds as follows: </del>  "A" sends a "ClientHello" to "B".

value and the receiving member's known identity.  See Selfie for details.  <ins> To illustrate the rerouting attack, consider three peers, "A", "B", and "C", who all know the PSK.  The attack proceeds as follows: </ins> "A" sends a "ClientHello" to "B".


Entropy properties of external PSKs may also affect TLS security properties.  For example, if a high entropy PSK is used, then PSK- only key establishment modes provide expected security properties for <del> TLS, including, for example, including establishing the same session keys between peers, secrecy of session keys, peer authentication, and downgrade protection.  See RFC8446, Section E.1 for an explanation of these properties.  However, these modes lack forward security. Forward security may be achieved by using a PSK-DH mode, or, alternatively, by using PSKs with short lifetimes. </del>  In contrast, if a low entropy PSK is used, then PSK-only key establishment modes are subject to passive exhaustive search attacks

Entropy properties of external PSKs may also affect TLS security properties.  For example, if a high entropy PSK is used, then PSK- only key establishment modes provide expected security properties for  <ins> TLS, including establishing the same session keys between peers, secrecy of session keys, peer authentication, and downgrade protection.  See RFC8446, Section E.1 for an explanation of these properties.  However, these modes lack forward security.  Forward security may be achieved by using a PSK-DH mode, or, alternatively, by using PSKs with short lifetimes. </ins> In contrast, if a low entropy PSK is used, then PSK-only key establishment modes are subject to passive exhaustive search attacks


This section lists some example use-cases where pair-wise external PSKs, i.e., external PSKs that are shared between only one server and <del> one client, have been used for authentication in TLS. </del>  Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known

This section lists some example use-cases where pair-wise external PSKs, i.e., external PSKs that are shared between only one server and  <ins> one client, have been used for authentication in TLS.  There was no attempt to prioritize the examples in any particular order. </ins> Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known


different online protocol. Intra-data-center communication.  Machine-to-machine communication <del> within a single data center or PoP may use externally provisioned PSKs, primarily for the purposes of supporting TLS connections with early data; see security-con for considerations when using early data with external PSKs. </del>  Certificateless server-to-server communication.  Machine-to- machine communication may use externally provisioned PSKs,

different online protocol. Intra-data-center communication.  Machine-to-machine communication  <ins> within a single data center or point-of-presence (PoP) may use externally provisioned PSKs, primarily for the purposes of supporting TLS connections with early data; see security-con for considerations when using early data with external PSKs. </ins> Certificateless server-to-server communication.  Machine-to- machine communication may use externally provisioned PSKs,


PSK into the devices, or using a Trust On First Use (TOFU) approach with a device completely unprotected before the first login did take place.  Many devices have very limited UI.  For <del> example, they may only have a numeric keypad or even less number of buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI. </del>  Some devices provision PSKs via an out-of-band, cloud-based syncing protocol. <del> Some secrets may be baked into or hardware or software device </del>  components.  Moreover, when this is done at manufacturing time, secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import.

PSK into the devices, or using a Trust On First Use (TOFU) approach with a device completely unprotected before the first login did take place.  Many devices have very limited UI.  For  <ins> example, they may only have a numeric keypad or even fewer buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI. </ins> Some devices provision PSKs via an out-of-band, cloud-based syncing protocol.  <ins> Some secrets may be baked into hardware or software device </ins> components.  Moreover, when this is done at manufacturing time, secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import.


identifiers have privacy implications; see endpoint-privacy. Each endpoint SHOULD know the identifier of the other endpoint with <del> which its wants to connect and SHOULD compare it with the other </del>  endpoint's identifier used in ImportedIdentity.context.  It is however important to remember that endpoints sharing the same group PSK can always impersonate each other.

identifiers have privacy implications; see endpoint-privacy. Each endpoint SHOULD know the identifier of the other endpoint with  <ins> which it wants to connect and SHOULD compare it with the other </ins> endpoint's identifier used in ImportedIdentity.context.  It is however important to remember that endpoints sharing the same group PSK can always impersonate each other.


The method the client instance uses to send an access token depends on whether the token is bound to a key, and if so which proofing method is associated with the key.  This information is conveyed in <del> the "key" and "proof" parameters in response-token-single. </del>  <del> If the "key" value is the boolean "false", the access token is a bearer token sent using the HTTP Header method defined in RFC6750. </del>  <del> The form parameter and query parameter methods of RFC6750 MUST NOT be used. </del>  <del> If the "key" value is the boolean "true", the access token MUST be sent using the same key and proofing mechanism that the client instance used in its initial request (or its most recent rotation). </del>  <del> If the "key" value is an object as described in key-format, the value of the "proof" field within the key indicates the particular proofing mechanism to use.  The access token is sent using the HTTP authorization scheme "GNAP" along with a key proof as described in binding-keys for the key bound to the access token.  For example, a "jwsd"-bound access token is sent as follows: </del>  [[ See issue #104 [47] ]]  7.3. Any keys presented by the client instance to the AS or RS MUST be

Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit a5ab40750ac9435b370bab7ded6dbdc60b35b01a https://deploy-preview-208--gnap-core-protocol-editors-URL
It may make sense to change the order to something like == && is present == && is absent == == && is present
I did changes for URL There are lots of other things that, I believe, could be improved & changed for the "Presenting Access Tokens" section and they will be addressed in separate PRs in the future.
Thank you, this is great! Aligns with the language in

The method the client instance uses to send an access token depends on whether the token is bound to a key, and if so which proofing method is associated with the key.  This information is conveyed in  <ins> the "bound" and "key" parameters in response-token-single and response-token-multiple responses. </ins>  <ins> If the "bound" value is the boolean "true" and the "key" is absent, the access token MUST be sent using the same key and proofing mechanism that the client instance used in its initial request (or its most recent rotation). </ins>  <ins> If the "bound" value is the boolean "true" and the "key" value is an object as described in key-format, the access token MUST be sent using the key and proofing mechanism defined by the value of the "proof" field within the key object. </ins>  <ins> The access token MUST be sent using the HTTP "Authorization" request header field and the "GNAP" authorization scheme along with a key proof as described in binding-keys for the key bound to the access token.  For example, a "jwsd"-bound access token is sent as follows: </ins>  <ins> If the "bound" value is the boolean "false", the access token is a bearer token that MUST be sent using the "Authorization Request Header Field" method defined in RFC6750. The "Form-Encoded Body Parameter" and "URI Query Parameter" methods of RFC6750 MUST NOT be used. </ins> [[ See issue #104 [47] ]] <ins> The client software MUST reject as an error a situation where the "bound" value is the boolean "false" and the "key" is present. </ins> 7.3. Any keys presented by the client instance to the AS or RS MUST be


REQUIRED.  A unique access token for continuing the request, in the format specified in response-token-single.  This access token MUST be bound to the client instance's key used in the request and <del> MUST NOT be a "bearer" token.  As a consequence, the "bound" field of this access token is always the boolean value "true" and the </del>  "key" field MUST be omitted.  This access token MUST NOT be usable at resources outside of the AS.  The client instance MUST present the access token in all requests to the continuation URI as

URL match the flags array in the token request. While this is technically a breaking change, I think we should consider this editorial as this should have been changed when we made the original change to use a flags array in the request in .
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: 8c793bb446d82f053536358106485568fc457842 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
You know, I had that thought, and I checked the request section and it doesn't have quotes. I'm going to add the quotes to both parts. This ended up with some other language changing, not just the examples, so let me know what you think.

REQUIRED.  A unique access token for continuing the request, in the format specified in response-token-single.  This access token MUST be bound to the client instance's key used in the request and  <ins> MUST NOT be a "bearer" token.  As a consequence, the "flags" array of this access token MUST NOT contain the string "bearer" and the </ins> "key" field MUST be omitted.  This access token MUST NOT be usable at resources outside of the AS.  The client instance MUST present the access token in all requests to the continuation URI as


ASCII characters to facilitate transmission over HTTP headers within other protocols without requiring additional encoding. <del> RECOMMENDED.  Flag indicating if the token is bound to the client instance's key.  If the boolean value is "true" or the field is omitted, and the "key" field is omitted, the token is bound to the request-client in its request for access.  If the boolean value is "true" or the field is omitted, and the "key" field is present, the token is bound to the key and proofing mechanism indicated in the "key" field.  If the boolean value is "false", the token is a bearer token with no key bound to it and the "key" field MUST be omitted. </del> REQUIRED for multiple access tokens, OPTIONAL for single access token.  The value of the "label" the client instance provided in the associated request-token, if present.  If the token has been

ASCII characters to facilitate transmission over HTTP headers within other protocols without requiring additional encoding.  REQUIRED for multiple access tokens, OPTIONAL for single access token.  The value of the "label" the client instance provided in the associated request-token, if present.  If the token has been


MUST be able to dereference or process the key information in order to be able to sign the request.  OPTIONAL.  Flag indicating a hint of AS behavior on token <del> rotation.  If this flag is set to the value "true", then the client instance can expect a previously-issued access token to continue to work after it has been rotate-access-token or the underlying grant request has been continue-modify, resulting in the issuance of new access tokens.  If this flag is set to the boolean value "false" or is omitted, the client instance can </del>  anticipate a given access token will stop working after token rotation or grant request modification.  Note that a token flagged as "durable" can still expire or be revoked through any normal

MUST be able to dereference or process the key information in order to be able to sign the request. <ins> OPTIONAL.  A set of flags that represent attributes or behaviors of the access token issued by the AS. The values of the "flags" field defined by this specification are as follows: This flag indicates whether the token is bound to the client instance's key.  If the "bearer" flag is present, the access token is a bearer token, and the "key" field in this response MUST be omitted.  If the "bearer" flag is omitted and the "key" field in this response is omitted, the token is bound the request-client in its request for access.  If the "bearer" flag is omitted, and the "key" field is present, the token is bound to the key and proofing mechanism indicated in the "key" field. </ins> OPTIONAL.  Flag indicating a hint of AS behavior on token  <ins> rotation.  If this flag is present, then the client instance can expect a previously-issued access token to continue to work after it has been rotate-access-token or the underlying grant request has been continue-modify, resulting in the issuance of new access tokens.  If this flag is omitted, the client instance can </ins> anticipate a given access token will stop working after token rotation or grant request modification.  Note that a token flagged as "durable" can still expire or be revoked through any normal


unless the client instance has specifically requested it by use of the "split" flag.  The following non-normative example shows a single access token bound to the client instance's key used in the initial request, with a management URL, and that has access to three described resources (one

unless the client instance has specifically requested it by use of the "split" flag. <ins> Flag values MUST NOT be included more than once. Additional flags can be defined by extensions using IANA. </ins> The following non-normative example shows a single access token bound to the client instance's key used in the initial request, with a management URL, and that has access to three described resources (one


sends the "split" flag as described in request-token-single. If the AS has split the access token response, the response MUST <del> include the "split" flag set to "true". </del>  [[ See issue #69 [17] ]]

sends the "split" flag as described in request-token-single. If the AS has split the access token response, the response MUST  <ins> include the "split" flag. </ins> [[ See issue #69 [17] ]]


multiple access token structure containing one access token. If the AS has split the access token response, the response MUST <del> include the "split" flag set to "true". </del>  Each access token MAY be bound to different keys with different proofing mechanisms.

multiple access token structure containing one access token. If the AS has split the access token response, the response MUST  <ins> include the "split" flag in the "flags" array. </ins> Each access token MAY be bound to different keys with different proofing mechanisms.


Indicates that interaction through some set of defined mechanisms needs to take place. <del> Claims about the RO as known and declared by the AS. </del>  An identifier this client instance can use to identify itself when making future requests. <del> An identifier this client instance can use to identify its current end-user when making future requests. </del> An error code indicating that something has gone wrong. In this example, the AS is returning an response-interact-redirect, a

Opaque identifiers provide a generic reference, so we can simplify the text. (mainly), and as a byproduct also and - removed userhandle from main response in section 3 changed title of section 3.4 (User -> Subject) and moved the text that requires RO = end-user at the top of the section, for clarity changed name (userhandle -> user) and wording in section 3.5. Maybe we could also simplify the title "Returning Dynamically-bound Reference Handles" into "Returning Reference Handles" (didn't do it yet).
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 73de700ce82846ec5e09f8f60550fac7bee0dfb5 Inspect the deploy log: Browse the preview:
With the adoption of the subject identifier format, we no longer need to have a GNAP-specific value and can instead leverage this more standard field. Alternatively, we could have a GNAP-specific subject identifier format, instead of a separate field.
In section 2.4 (Requesting User Information), the first sentence starts with: If the client instance is requesting information about the RO from the AS, ... From the title, the acronym "RO" should be changed into "end-user". The case where the RO is also the end-user is a specific case. This leads to the following change: If the client instance is requesting information about the end-user from the AS, ... In the following sentences of this section, RO should be changed into end-user.
The current text really means RO, and generally considers the case end-user = RO. Any other case would even trigger an error: "If the identified end-user does not match the RO present at the AS during an interaction step, the AS SHOULD reject the request with an error." (section 2.4) Which makes sense because why would we return something about the RO to a potentially unknown end-user? (the only problem is that this wording is buried in the text, so it's hard to understand) Back to the general case: The RO is in control of policies at the AS. The end-user is in control of a client and a request to the AS. The end-user and client may or may not have any prior relationship with the AS. The subject info is what is known by the AS (in theory could be RO and maybe end-user, but notice that in the terminology, we define the end-user as a natural person and the RO as a subject entity). I think we should clarify when we could have a remote RO too. Then do we even return a result if the AS knows something about the end-user? (different from RO in that case). Plus we need to keep in mind that we also use sub_ids for URL In general, we might want to avoid the term "user" as it is not specific enough.
The title has been changed into "Requesting Subject information". This title is incorrect as long as a subject can be also an organization or a device. An AS can hold information about an end-user or about RO when the RO is a human being. It does not hold information about organizations or devices. However, an end-user may belong to some organizations or/and use some devices. IMO, I would replace it by "Requesting end-user Information". If an AS holds information about an end-user, it seems logical that the end-user should have access to it. If it happens that the end-user has also a RO account on the AS, then it should also have access to it. In such a case, another section with the following title "Requesting RO Information" should be created. RO = end-user was a common case in OAuth. In GNAP and in the general case a RO is different from an end-user and an AS may have no relationship with any RO (e.g. when attributes only are being used).
I guess you refer to "2.2. Requesting Subject Information". We might have to harmonize a bit, but for instance "2.3. Identifying the Client Instance" might very well hold information about devices or at least the software running on it (that's the point of client software attestation to be discussed in ) We don't always know in advance whether it will be a RO or an end-user only, so the proposal isn't always applicable.
I was indeed referring to "2.2. Requesting Subject Information" which has no relationship with "2.3. Identifying the Client Instance". This means that your arguments do not apply to section 2.2. and, by implication, that my argumentation currently remains valid.
Well, I take the point in consideration but I don't think we should base our reasoning on the structure of sections, which can change
Identifying the User by Reference: Editor's note: We might be able to fold this function into an unstructured user assertion reference issued by the AS to the RC. We could put it in as an assertion type of "gnap_reference" or something like that. Downside: it's more verbose and potentially confusing to the client developer to have an assertion-like thing that's internal to the AS and not an assertion.
Why an assertion? Is that reference supposed to be linked to a session (cf "represent the same end-user to the AS over subsequent requests") or can it be persistent? I would see that more as an opaque identifier, rather than an assertion. Something like: asref seems a bit specific to GNAP (reference managed by the AS) but it could always be read "as a reference" in a more general setting. There's a variety of generic names that we could choose if needed, localuid, internal_uid, etc. But that really asks what additional types we could define as part of secevents (section 7.1.2). Beyond the case mentioned here, it would be most useful as an opaque identifier when RO != end-user, to avoid leaking private info about the RO (although currently we don't seem to cover that case yet) It's indeed more verbose than "user": "XUT2MFM1XBIKJKSDU8QM" but at least it's always the same structure (doesn't depend whether it's a reference or not), and it also makes the type more explicit.
A subject identifier makes sense here, and I agree that it should be a new value to let us constrain it to the GNAP context.
Fixed by SECEVENT opaque identifiers
I don't think this goes far enough -- I am thinking that with the opaque identifiers we can now simply return a with a format of that the client can be allowed to send in a follow-up request if it wants to. This way they all get treated equally, there's no special field anymore.

Indicates that interaction through some set of defined mechanisms needs to take place.  <ins> Claims about the RO as known and declared by the AS, as described in response-subject. </ins> An identifier this client instance can use to identify itself when making future requests.  An error code indicating that something has gone wrong. In this example, the AS is returning an response-interact-redirect, a


If information about the RO is requested and the AS grants the client instance access to that data, the AS returns the approved information <del> in the "subject" response field.  This field is an object with the following OPTIONAL properties. </del>  An array of subject identifiers for the RO, as defined by I- D.ietf-secevent-subject-identifiers.

If information about the RO is requested and the AS grants the client instance access to that data, the AS returns the approved information  <ins> in the "subject" response field.  The AS MUST return the "subject" field only in cases where the AS is sure that the RO and the end-user are the same party.  This can be accomplished through some forms of authorization. This field is an object with the following OPTIONAL properties. </ins> An array of subject identifiers for the RO, as defined by I- D.ietf-secevent-subject-identifiers.


information through an identity API.  The definition of such an identity API is out of scope for this specification. <del> The AS MUST return the "subject" field only in cases where the AS is sure that the RO and the end-user are the same party.  This can be accomplished through some forms of authorization. </del> Subject identifiers returned by the AS SHOULD uniquely identify the RO at the AS.  Some forms of subject identifier are opaque to the client instance (such as the subject of an issuer and subject pair),

information through an identity API.  The definition of such an identity API is out of scope for this specification.  Subject identifiers returned by the AS SHOULD uniquely identify the RO at the AS.  Some forms of subject identifier are opaque to the client instance (such as the subject of an issuer and subject pair),


All dynamically generated handles are returned as fields in the root JSON object of the response.  This specification defines the <del> following dynamic handle returns, additional handles can be defined in IANA. </del>  A string value used to represent the information in the "client" object that the client instance can use in a future request, as described in request-instance. <del> A string value used to represent the current user.  The client instance can use in a future request, as described in request- user-reference. This non-normative example shows two handles along side an issued </del>  access token. [[ See issue #77 [23] ]]

All dynamically generated handles are returned as fields in the root JSON object of the response.  This specification defines the  <ins> following dynamic handle return, additional handles can be defined in IANA. </ins> A string value used to represent the information in the "client" object that the client instance can use in a future request, as described in request-instance.  <ins> This non-normative example shows one handle along side an issued </ins> access token. [[ See issue #77 [23] ]]


REQUIRED.  The URI at which the client instance can make continuation requests.  This URI MAY vary per request, or MAY be <del> stable at the AS if the AS includes an access token.  The client instance MUST use this value exactly as given when making a continue-request. </del>  RECOMMENDED.  The amount of time in integer seconds the client instance SHOULD wait after receiving this continuation handle and

In the current version, the AS must include an access token. "if the AS includes an access token" sounds like the inclusion of an access token is optional.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 323dd6c268368857c2d9942048f94658b806b8ad Inspect the deploy log: Browse the preview:

REQUIRED.  The URI at which the client instance can make continuation requests.  This URI MAY vary per request, or MAY be  <ins> stable at the AS.  The client instance MUST use this value exactly as given when making a continue-request. </ins> RECOMMENDED.  The amount of time in integer seconds the client instance SHOULD wait after receiving this continuation handle and


If the AS determines that the request cannot be issued for any reason, it responds to the client instance with an error message. <del> The error code is one of the following, with additional values available in IANA: </del> [[ See issue #79 [15] ]] 3.7.

for
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: c7273a059b212bf18879f131a5a18d9a776a2918 Inspect the deploy log: Browse the preview:
Error Response: Editor's note: I think we will need a more robust error mechanism, and we need to be more clear about what error states are allowed in what circumstances. Additionally, is the "error" parameter exclusive with others in the return?
As a starting point, I would suggest adding these sentences The error code parameter MUST be required and its value SHOULD be limited to ASCII characters. The error code indicates that a request is malformed. The AS MUST return an HTTP 401 (Unauthorized) status code to indicate that it can't identify a client instance (the error code can be ). The AS MUST return an HTTP 401 (Unauthorized) status code to indicate that it can't authenticate a client instance (the error code can be ). The AS MAY uncover additional information about the cause of the error when it can authenticate a client instance (the error code can be , , and so on).
Addressed by , still need error codes for things like token management.
The type of the of the error property in a response is currently ambiguous. In section 3 it is defined as an and in section 3.6 it is defined as a .
NAME thanks for catching that -- looks like both "error" and "errordescription" should be added to the list of parameters. I think the intent might have been for the value of "error" to be an object with "errorcode" and "error_description" fields inside of it though, so it might be better to align things in that direction instead. Do you have thoughts on which is preferable? Interop testing of error conditions is really difficult in practice, so this is a great catch!
Yaron: The AS MUST ignore any unknown extension. Justin: I’m OK with this stance, but it needs to be consistent throughout the protocol, not just at this level. Yaron: we can actually have one policy for an AS that doesn't understand something defined in the RFC (e.g. a token binding method) vs. extensions. Unknown extensions clearly must be ignored, otherwise you cannot deploy extensions incrementally. For RFC elements, this is more nuanced.
With the guidance on extension points from and error codes from and similar, this should now be covered by the current text.

If the AS determines that the request cannot be issued for any reason, it responds to the client instance with an error message.  [[ See issue #79 [15] ]] 3.7.


Any keys presented by the client instance to the AS or RS MUST be validated as part of the request in which they are presented.  The <del> type of binding used is indicated by the proof parameter of the key object in key-format.  Values defined by this specification are as follows: </del>  Additional proofing methods are defined by IANA.  All key binding methods used by this specification MUST cover all relevant portions of the request, including anything that would change the nature of the request, to allow for secure validation of

Expands the key parameter to allow it to be an object or a string, to facilitate methods with multiple parameters such as HTTPSig.
To edit notification comments on pull requests, go to your .
Some key proofing methods have additional options that could be signaled in the GNAP protocol structure. Notable, HTTP Message Signatures has the ability to use different HTTP Signing Algorithms and different HTTP Digest Algorithms. The field could be changed to an object to accomodate this kind of use, allowing each proofing method to define its own parameters: Each method can also define "Default" values for missing parameters, allowing this to collapse in the simple case back to a string as it is today: These string values would have a deterministic expansion defined in the core protocol.
Note that the httpsig document itself wavers between and and does not require either of them. Though maybe this is OK if the current document makes mandatory for the appropriate cases.
There are some updates pending in the Digest draft -- once that's out, we'll reference using as that's the most appropriate for our use case, and examples will be updated.

Any keys presented by the client instance to the AS or RS MUST be validated as part of the request in which they are presented.  The  <ins> type of binding used is indicated by the "proof" parameter of the key object in key-format.  This parameter is formally specified by an object with at least the following member: Individual methods MAY define additional parameters as members in this object. Values for the "method" defined by this specification are as follows: </ins> Additional proofing methods are defined by IANA. <ins> For example, the "httpsig" method can be specified with its parameters as: If additional parameters are not required or used for a specific method, the method MAY be passed as a string instead of an object. For example, the "mtls" method with no additional parameters could be sent by the client instance as: The AS would map this to the equivalent expanded form as follows: </ins> All key binding methods used by this specification MUST cover all relevant portions of the request, including anything that would change the nature of the request, to allow for secure validation of


7.3.1. <del> This method is indicated by "httpsig" in the "proof" field.  The signer creates an HTTP Message Signature as described in I-D.ietf- httpbis-message-signatures. </del>  The covered components of the signature MUST include the following:

7.3.1.  <ins> This method is indicated by the method value "httpsig".  The signer creates an HTTP Message Signature as described in I-D.ietf-httpbis- message-signatures.  This method defines the following parameters: </ins> The covered components of the signature MUST include the following:


7.3.2. <del> This method is indicated by "mtls" in the "proof" field.  The signer presents its TLS client certificate during TLS negotiation with the verifier. </del>  In this example, the certificate is communicated to the application through the "Client-Cert" header from a TLS reverse proxy, leading to

7.3.2.  <ins> This method is indicated by the method value "mtls".  This method defines no additional parameters.  The signer presents its TLS client certificate during TLS negotiation with the verifier. </ins> In this example, the certificate is communicated to the application through the "Client-Cert" header from a TLS reverse proxy, leading to


7.3.3. <del> This method is indicated by "jwsd" in the "proof" field.  A JWS RFC7515 object is created as follows: </del>  To protect the request, the JOSE header of the signature contains the following claims:

7.3.3.  <ins> This method is indicated by the method value "jwsd".  This method defines no additional parameters.  A JWS RFC7515 object is created as follows: </ins> To protect the request, the JOSE header of the signature contains the following claims:


7.3.4. <del> This method is indicated by "jws" in the "proof" field.  A JWS RFC7515 object is created as follows: </del>  To protect the request, the JWS header contains the following claims.

7.3.4.  <ins> This method is indicated by the method value "jws".  This method defines no additional parameters.  A JWS RFC7515 object is created as follows: </ins> To protect the request, the JWS header contains the following claims.


This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and <del> other elements.  Some examples use a single trailing backslash '' to </del>  indicate line wrapping for long values, as per RFC8792.  The "" character and leading spaces on wrapped lines are not part of the value.

Deploy Preview for gnap-resource-servers-editors-draft ready! Built Explore the source changes: 611af53328d71bac58f517702c5775a9c514d88d Inspect the deploy log: Browse the preview:

This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and  <ins> other elements.  Some examples use a single trailing backslash "" to </ins> indicate line wrapping for long values, as per RFC8792.  The "" character and leading spaces on wrapped lines are not part of the value.


This section defines how proxies operate in a group communication scenario.  In particular, sec-proxy-forward defines operations of forward-proxies, while sec-proxy-reverse defines operations of <del> reverse-proxies. </del>  3.5.1.

text for proxy security cases
Reverse proxy may act as origin server and hence client doesn't use e2e security to server group. However, in other cases a reverse proxy may assume the client uses e2e OSCORE security and not add any security by itself. To consider all the different, possible/valid cases for this. And see if it's different for forward proxies.
One particular example is a client that connects over CoAP+TLS+TCP (or CoAP+DTLS) to the reverse-proxy, where the proxy uses OSCORE security for the multicast request. The client is not aware of the (group) security material which the proxy and servers have.
At high level, there are 4 different potential cases of "proxying with security". Forward proxy with e2e security [=Group oscore e2e via proxy] Forward proxy with two-leg security [=unicast OSCORE or DTLS on 1st leg, with group OSCORE on 2nd leg] Reverse proxy with e2e security [=Group oscore e2e via proxy] Reverse proxy with two-leg security [=unicast OSCORE or DTLS on 1st leg, with group OSCORE on 2nd leg] Currently the draft doesn't say anything about these combinations, which are valid, which not, and where to find the security solution to them (e.g. a pointer to draft-groupcomm-proxy for covering most of these cases) This text/analysis could be a new Section 5.3 "Proxy Security" or so. Note: cases 2 and 4 depend on a 100% trusted proxy so no e2e security model. The client in this case is not even aware necessarily of the existence of Group-OSCORE. The proxy stores the "group member identity" to be used to make the Group OSCORE protected request. This may be a single identity, or a separate identity for each authorized user of the Proxy service. Case 1 and 3 most likely means OSCORE-in-OSCORE is needed?
It seems like a good idea. Intermediaries are usually considered non-trusted, hence the interest for an actual e2e security model between origin client and origin servers. How would the proxy store and use a "group member identity" ? Even if the proxy somehow obtains multiple different Sender IDs from the Group Manager (i.e., one for each authorized user of the proxy service), the proxy would have to sign a Group OSCORE protected request with a private key of its own (possibly one per corresponding Sender ID), which is not in control of the actual origin client. With such a level of trust on the proxy, and with a client not interested in e2e security anyway, it would be just easier to think of the proxy simply as another single member of the same OSCORE group including the servers, thus sacrificing verifiable data authorship/origin. Maybe this might be useful/applicable for case 4, with a client anyway likely unaware of what happens beyond the reverse-proxy and to be actually reaching a group of servers. Not sure about case 2, where the client would be aware of an actual group of servers it tries to reach. Yes, when exactly OSCORE is also conveniently used between Client and Proxy, to fulfill REQ2 from URL : REQ2. The CoAP proxy MUST identify a client sending a CoAP group request, in order to verify whether the client is allowed-listed to do so. For example, this can rely on one of the following ... Note that this requirement applies even in case end-to-end security is not enforced between client and servers.
Agree, in the two-legs security case it seems sufficient that the proxy has one "identity" within the group. And I agree that this proxy would most likely be a reverse proxy Case 4 i.e. it operates like a (trusted!) origin server. By definition of a reverse proxy , it has to be trusted just like a client trusts an origin server with being able to know and manipulate the served content.
This issue was addressed in Section 5.3 of version -04. NAME , can we close it?
Yes!
Looks good! See inline some proposed rephrasing.

This section defines how proxies operate in a group communication scenario.  In particular, sec-proxy-forward defines operations of forward-proxies, while sec-proxy-reverse defines operations of  <ins> reverse-proxies.  Security operations for a proxy are discussed later in chap-proxy-security. </ins> 3.5.1.


groupcomm, and it is RECOMMENDED to perform them according to the approach described in I-D.ietf-ace-key-groupcomm-oscore.  6. This section provides security considerations for CoAP group

groupcomm, and it is RECOMMENDED to perform them according to the approach described in I-D.ietf-ace-key-groupcomm-oscore. <ins> 5.3. Different solutions may be selected for secure group communication via a proxy depending on proxy type, use case and deployment requirements.  In this section the options based on Group OSCORE are listed. For a client performing a group communication request via a forward- proxy, end-to-end security should be implemented.  The client then creates a group request protected with Group OSCORE and unicasts this to the proxy.  The proxy adapts the request from a forward-proxy request to a regular request and multicasts this adapted request to the indicated CoAP group.  During the adaptation, the security provided by Group OSCORE persists, in either case of using the group mode or using the pairwise mode.  The first leg of communication from client to proxy can optionally be further protected, e.g., by using (D)TLS and/or OSCORE. For a client performing a group communication request via a reverse- proxy, either end-to-end-security or hop-by-hop security can be implemented.  The case of end-to-end security is the same as for the forward-proxy case. The case of hop-by-hop security is only possible if the proxy can be completely trusted and it is configured as a member of the OSCORE security group(s) that it needs to access, on behalf of clients.  The first leg of communication between client and proxy is then protected with a security method for CoAP unicast, such as (D)TLS, OSCORE or a combination of such methods.  The second leg between proxy and servers is protected using Group OSCORE.  This can be useful in applications where for example the origin client does not implement Group OSCORE, or the group management operations are confined to a particular network domain and the client is outside this domain. For all the above cases, more details on using Group OSCORE are defined in I-D.tiloca-core-groupcomm-proxy. </ins> 6. This section provides security considerations for CoAP group


secure delegation.  The zone signing and secure delegation may be performed either by the Homenet Naming Authority or by the Outsourcing Infrastructure. sec-dnssec-deplyment discusses these two <del> alternatives. sec-views discusses the consequences of publishing multiple representations of the same zone also commonly designated as views.  This section provides guidance to limit the risks associated with multiple views.  sec-reverse discusses management of the reverse zone. sec-renumbering discusses how renumbering should be handled. </del>  Finally, sec-privacy and sec-security respectively discuss privacy and security considerations when outsourcing the Homenet Zone.  3. Customer Premises Equipment: (CPE) is a router providing

…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.

secure delegation.  The zone signing and secure delegation may be performed either by the Homenet Naming Authority or by the Outsourcing Infrastructure. sec-dnssec-deplyment discusses these two  <ins> alternatives. sec-reverse discusses management of the reverse zone. sec-renumbering discusses how renumbering should be handled. </ins> Finally, sec-privacy and sec-security respectively discuss privacy and security considerations when outsourcing the Homenet Zone. <ins> The Homenet Zone is expected to host public information only.  It is not the scope of this DNS service to define local home network boundaries.  Instead, local scope information is expected to be provided to the home network using local scope naming services. mDNS RFC6762 DNS-SD RFC6763 are two examples of these services.  Currently mDNS is limited to a single link network.  However, future protocols are expected to leverage this constraint as pointed out in RFC7558. </ins> 3. Customer Premises Equipment: (CPE) is a router providing


Server.  On the other hand, if the HNA signs the Homenet Zone itself, the zone would be collected by the Synchronization Server and directly transferred to the Public Authoritative Server(s).  These <del> policies are discussed and detailed in sec-dnssec-deplyment and sec- views. </del>  4.2.

Server.  On the other hand, if the HNA signs the Homenet Zone itself, the zone would be collected by the Synchronization Server and directly transferred to the Public Authoritative Server(s).  These  <ins> policies are discussed and detailed in sec-dnssec-deplyment. </ins> 4.2.


As depicted in fig-naming-arch and fig-auth-servers, the Public Homenet Zone is hosted on the Public Authoritative Server(s), whereas <del> the Homenet Zone is hosted on the HNA.  Motivations for keeping these two zones identical are detailed in sec-views, and this section considers that the HNA builds the zone that will be effectively published on the Public Authoritative Server(s).  In other words "Homenet to Public Zone transformation" is the identity also commonly designated as "no operation" (NOP). </del>  In that case, the Homenet Zone should configure its Name Server RRset (NS) and Start of Authority (SOA) with the values associated with the

As depicted in fig-naming-arch and fig-auth-servers, the Public Homenet Zone is hosted on the Public Authoritative Server(s), whereas  <ins> the Homenet Zone is hosted on the HNA.  This section considers that the HNA builds the zone that will be effectively published on the Public Authoritative Server(s).  In other words "Homenet to Public Zone transformation" is the identity also commonly designated as "no operation" (NOP). </ins> In that case, the Homenet Zone should configure its Name Server RRset (NS) and Start of Authority (SOA) with the values associated with the


Reasons for signing the zone by the HNA are: <del> 1) Keeping the Homenet Zone and the Public Homenet Zone equal to </del>  securely optimize DNS resolution.  As the Public Zone is signed with DNSSEC, RRsets are authenticated, and thus DNS responses can be validated even though they are not provided by the

Reasons for signing the zone by the HNA are:  <ins> Keeping the Homenet Zone and the Public Homenet Zone equal to </ins> securely optimize DNS resolution.  As the Public Zone is signed with DNSSEC, RRsets are authenticated, and thus DNS responses can be validated even though they are not provided by the


otherwise a resolution with the Public Authoritative Server(s) would be performed. <del> 2) Keeping the Homenet Zone and the Public Homenet Zone equal to </del>  securely address the connectivity disruption independence detailed in RFC7368 section 4.4.1 and 3.7.5.  As local lookups are possible in case of network disruption, communications within the home

otherwise a resolution with the Public Authoritative Server(s) would be performed.  <ins> Keeping the Homenet Zone and the Public Homenet Zone equal to </ins> securely address the connectivity disruption independence detailed in RFC7368 section 4.4.1 and 3.7.5.  As local lookups are possible in case of network disruption, communications within the home


lookup would provide DNS as opposed to DNSSEC responses provided by the Public Authoritative Server(s). <del> 3) Keeping the Homenet Zone and the Public Homenet Zone equal to guarantee coherence between DNS responses.  Using a unique zone is one way to guarantee uniqueness of the responses among servers and places.  Issues generated by different views are discussed in more details in sec-views. 4) Privacy and Integrity of the DNSSEC Homenet Zone are better guaranteed.  When the Zone is signed by the HNA, it makes modification of the DNS data -- for example for flow redirection -- impossible.  As a result, signing the Homenet Zone by the HNA provides better protection for end user privacy. </del>  Reasons for signing the zone by the Outsourcing Infrastructure are:

lookup would provide DNS as opposed to DNSSEC responses provided by the Public Authoritative Server(s).  <ins> Privacy and Integrity of the DNSSEC Homenet Zone are better guaranteed.  When the Zone is signed by the HNA, it makes modification of the DNS data -- for example for flow redirection -- impossible.  As a result, signing the Homenet Zone by the HNA provides better protection for end user privacy. </ins> Reasons for signing the zone by the Outsourcing Infrastructure are:


7. <del> The Homenet Zone provides information about the home network.  Some users may be tempted to have provide responses dependent on the origin of the DNS query.  More specifically, some users may be tempted to provide a different view for DNS queries originating from the home network and for DNS queries coming from the Internet.  Each view could then be associated with a dedicated Homenet Zone. <!--Regarding {{fig-naming-arch}}, an example of an implementation of two distinct view could be the Homenet Zone that describes the homenet view and the Public Homenet Zone that contains the Internet view, with these two zones being different.--> Note that this document does not specify how DNS queries originating from the home network are addressed to the Homenet Zone.  This could be done via hosting the DNS resolver on the HNA for example. This section is not normative. sec-reasons details why some nodes may only be reachable from the home network and not from the global Internet. sec-consequences briefly describes the consequences of having distinct views such as a "home network view" and an "Internet view".  Finally, sec-guidance provides guidance on how to resolve names that are only significant in the home network, without creating different views. 7.1. The motivation for supporting different views is to provide different answers dependent on the origin of the DNS query, for reasons such as: 1: An end user may want to have services not published on the Internet.  Services like the HNA administration interface that provides the GUI to administer your HNA might not seem advisable to publish on the Internet.  Similarly, services like the mapper that registers the devices of your home network may also not be desirable to be published on the Internet.  In both cases, these services should only be known or used by the network administrator.  To restrict the access of such services, the home network administrator may choose to publish these pieces of information only within the home network, where it might be assumed that the users are more trusted than on the Internet.  Even though this assumption may not be valid, at least this may reduce the surface of any attack. 2: Services within the home network may be reachable using non global IP addresses.  IPv4 and NAT may be one reason.  On the other hand IPv6 may favor link-local or site-local IP addresses.  These IP addresses are not significant outside the boundaries of the home network.  As a result, they MAY be published in the home network view, and SHOULD NOT be published in the Public Homenet Zone. 7.2. Enabling different views leads to a non-coherent naming system. Depending on where resolution is performed, some services will not be available.  This may be especially inconvenient with devices with multiple interfaces that are attached both to the Internet via a 3G/4G interface and to the home network via a WLAN interface. Devices may also cache the results of name resolution, and these cached entries may no longer be valid if a mobile device moves between a homenet connection and an internet connection e.g. a device temporarily loses wifi signal and switches to 3G. Regarding local-scope IP addresses, such devices may end up with poor connectivity.  Suppose, for example, that DNS resolution is performed via the WLAN interface attached to the HNA, and the response provides local-scope IP addresses, but the communication is initiated on the 3G/4G interface.  Communications with local-scope addresses will be unreachable on the Internet, thus aborting the communication.  The same situation occurs if a device is flip / flopping between various WLAN networks. Regarding DNSSEC, if the HNA does not sign the Homenet Zone and outsources the signing process, the two views are different, because one is protected with DNSSEC whereas the other is not.  Devices with multiple interfaces will have difficulty securing the naming resolution, as responses originating from the home network may not be signed. For devices with all its interfaces attached to a single administrative domain, that is to say the home network, or the Internet.  Incoherence between DNS responses may still also occur if the device is able to perform DNS resolutions both using the DNS resolving server of the home network, or one of the ISP.  DNS resolution performed via the HNA or the ISP resolver may be different than those performed over the Internet. 7.3. As documented in sec-consequences, it is RECOMMENDED to avoid different views.  If network administrators choose to implement multiple views, impacts on devices' resolution SHOULD be evaluated. As a consequence, the Homenet Zone is expected to be an exact copy of the Public Homenet Zone.  As a result, services that are not expected to be published on the Internet SHOULD NOT be part of the Homenet Zone, local-scope addresses SHOULD NOT be part of the Homenet Zone, and when possible, the HNA SHOULD sign the Homenet Zone. The Homenet Zone is expected to host public information only.  It is not the scope of the DNS service to define local home network boundaries.  Instead, local scope information is expected to be provided to the home network using local scope naming services. mDNS RFC6762 DNS-SD RFC6763 are two examples of these services.  Currently mDNS is limited to a single link network.  However, future protocols are expected to leverage this constraint as pointed out in RFC7558. 7.4. </del> This section is focused on the Homenet Reverse Zone. Firstly, all considerations for the Homenet Zone apply to the Homenet

7.  This section is focused on the Homenet Reverse Zone. Firstly, all considerations for the Homenet Zone apply to the Homenet


This document uses the following terms: Appraisal Policy for Evidence: A set of rules that direct how a <del> verifier evaluates the validity of information about an Attester. </del>  Compare /security policy/ in [RFC4949]. Appraisal Policy for Attestation Result: A set of rules that <del> direct how a Relying Party evaluates the validity of information about an Attester.  Compare /security policy/ in [RFC4949]. </del>  Attestation Result: The evaluation results generated by a Verifier, typically including information about an Attester, where

When comparing the term 'Appraisal Policy for Evidence' and 'Appraisal Policy for Attestation Result', they are both saying 'evaluates the validity of information about an Attester'. This makes me feel Verifier and Relying Party are doing the same things and they are redundant. I think it's more appropriate to say that the Relying Party evaluates the evaluation results generated by the Verifiers.

This document uses the following terms: Appraisal Policy for Evidence: A set of rules that direct how a  <ins> Verifier evaluates the validity of information about an Attester. </ins> Compare /security policy/ in [RFC4949]. Appraisal Policy for Attestation Result: A set of rules that  <ins> direct how a Relying Party uses the evaluation results about an Attester generated by the Verifiers.  Compare /security policy/ in [RFC4949]. </ins> Attestation Result: The evaluation results generated by a Verifier, typically including information about an Attester, where