jiebi/CodeConvo huggingface dataset:
Change:
With static Diffie-Hellman key authentication, the authenticating endpoint can deny having participated in the protocol. <del> Earlier versions of EDHOC have been formally analyzed Jacomme23 Norrman20 Bruni18 and the specification has been updated based on the analysis. </del> <ins> Earlier versions of EDHOC have been formally analyzed Bruni18 Norrman20 CottierPointcheval22 Jacomme23 GuentherIlunga22 and the specification has been updated based on the analysis. </ins> 8.2.

Discussion:
Adding two further analyses that contributed to EDHOC (): Cottier, Pointcheval: "Security Analysis of the EDHOC protocol". Sep 2022. URL Günther, Ilunga: "Careful with MAc-then-SIGn: A Computational Analysis of the EDHOC Lightweight Authenticated Key Exchange Protocol". Dec 2022. URL
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)
Change:
IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for <del> connection_id(TBD1) defined in this document. </del> <ins> connection_id(TBD1) as described in the table below.  IANA is requested to add an extra column to the TLS ExtensionType Values registry to indicate whether an extension is only applicable to DTLS. Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document describes an extension for DTLS 1.2 only; it is not to TLS (1.3). The DTLS 1.3 functionality is described in I-D.ietf-tls-dtls13. </ins> IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType <del> Registry". </del> <ins> Registry".  The tls12_cid ContentType is only applicable to DTLS 1.2. </ins>

Discussion:
... IANA consideration section based on issue raised by Sean (see URL) ... Security consideration section based on issue raised by Thomas (see URL)
This PR aims to replace PR & PR
A couple of tweaks are needed for the IANA Considerations Section: Based on input from the IANA TLS DEs, it seems like we need a column added to the TLS ExtensionType Values registry to indicate that an extension is DTLS-only. The column values for TLS 1.3 and Recommended are missing. Suggest blank for TLS 1.3 and N for Recommended. Add a note to say that connectionid is DTLS1.2 only. Add instructions for IANA to assign "Y" to DTLS-okay column for tls12cid content type.
That results in "DTLS only" for TLS extensions and "DTLS-OK" for TLS parameters. I'm not sure, if that just represents more the "current" usage than the "logic" behind it. I would be afraid, that this will hold up other ideas, which doesn't match that "only for extensions / ok for parameters" pattern.
I am not sure what "DTLS-OK" for TLS parameters means
For TLS parameters there's a column "DTLS-OK", And for TLS extensions a column "DTLS only". Does this explain my comment?
We added text to the draft-ietf-tls-dtls-connection-id-06 about the IANA consideration section. I believe this issue is closed.
Change:
wrapping: Describes the wrapping of messages within HTTP requests/ responses. <del> server-config: Describes how HTTP clients retrieve server </del> <ins> server-config: Describes how HTTP Clients retrieve server </ins> configurations and key commitments. issuance: Describes how issuance requests are performed via a HTTP

Discussion:
cc NAME for review. Mainly just removing the interfaces that were previously present and using the API functions from the protocol directly. I've also changed some of the wording around the key registry, and replaced client -> Client and server -> Server. Let me know if there is anything that you think I've missed.
We currently have interfaces in the architecture document that lay out how messages should be sent and received. I think the architecture document should be solely focused on the building of the ecosystem in a way that maintains the utility of the privacy and security guarantees made by the protocol. The interfaces are mainly used by the HTTP API doc, and so I think this will be a better home for them.
I've removed the interfaces from the architecture doc () and used the protocol API directly in the HTTP doc ()
Change:
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> Privacy and security properties not provided by PSKs are also included. </ins> 1.

Discussion:
Builds on , and , and . cc NAME NAME NAME -- please review so we can submit today!
There are two numbered lists both of which only seem to have 1s? I see that you have removed the text on security weaknesses of PSKs (lack of identity protection/forward secrecy etc.) and also removed the reference to RFC 8773. I am completely fine with both as long as we provide a convincing answer to John's review.
Markdown handles the numbering for us. We have a section on identity protection, and the recommendations discuss forward secrecy, so I think more is redudant. No, that's still there.
John wrote: There also several weaknesses/limitation that are hinted at in RFC 8446 which apply for two-party PSK authenticated connections. As this is a guidance document for all uses of external PSK, I think this document should bring up and expand upon: Key Compromise Impersonation (KCI) resistance Protection of endpoint identities Forward secret with respect to long-term keys (psk_ke only) An additional security property given by signature authentication but not psk authentication is non-repudiation. As stated by Wikipedia “By this property, an entity that has signed some information cannot at a later time deny having signed it.”
This is a fair comment and I don't see any reason not to add these
NAME can you please send a PR?
Closing as resolved (by ).
The draft says “OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites.” John wrote: I assume this is not the case for TLS 1.3 as the cipher suites in TLS 1.3 are independent of the authentication.
I guess it would help to clarify. In my opinion, we should only look at APIs of TLS 1.3.
I fixed this directly on main.
The draft currently says "It is NOT RECOMMENDED to share the same PSK between more than one client and server." John says: group PSK violates both “peer authentication” and “downgrade protection property”. It also violates “secrecy of the session keys”. Two-party PSK already does not provide “Key Compromise Impersonation (KCI) resistance” and “Protection of endpoint identities” and pskkey does not provide “Forward secret with respect to long-term keys”.

So when pskke is used in a group, the only property left is “Uniqueness of the session keys”...I am skeptical to introduce this new group PSK mode in an informal guidance document. If group PSK should be allowed, it should be more clearly declared as a new mode of TLS 1.3 and the security properties given and not given should be more clearly stated.
I guess John thinks NOT RECOMMENDED is not sufficient and we should stronger language like SHALL NOT.
Change:
respond to this request, it instead uses RFC7540 to send the contents of push messages as they are sent by application servers. <ins> A user agent MAY include a Urgency header field in its request.  The push service MUST only deliver messages with an urgency greater than or equal to the value of the header field as defined in the urgency_values. </ins> Each push message is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE.  This GET request is made to the push message resource that was created by the push service when the

Discussion:
Should we include a reference to URL - perhaps in Acknowledgements?
I don't care about acknowledgments for -nice. But I do care about the issues that I raised on the list.
Change:
We sometimes refer to this message as the _report_. The message contains the "task_id" of the previous request.  It also includes the time (in seconds since the beginning of UNIX time) at which the <del> report was generated.  The rest of the message consists of the encrypted input shares, each of which has the following structure: </del> <ins> report was generated.  This field is present to ensure that each report is included in at most one batch.  The rest of the message consists of the encrypted input shares, each of which has the following structure: </ins> "config_id" is equal to "HpkeConfig.id", where "HpkeConfig" is the aggregator's key config.

Discussion:
Partially addresses via clarification. Intra-batch replay attacks need more text.
NAME I was going to file a separate issue to discuss it. Stay tuned!
Currently, clients specify the report timestamp when uploading a report for a task. Presumably this timestamp is used to determine the window/batch in which a report is aggregated. Do we care if clients can spoof or change this timestamp to put reports into different batches? Since clients have no understanding of what batch their report goes into, and this is something that aggregators manage, perhaps we should drop this and let the aggregators figure out the report<>batch grouping?
Yes, that's the idea. We have no way of ensuring that the client doesn't lie about the timestamp. This "attack" is akin to the client just lying about the input itself (see ): It's something we can't do anything about, short of using a secure enclave on the client's machine. I think dealing with these problems is orthogonal to the spec here. On the other hand, it should our goal to allow an honest aggregator to ensure that each report appears in most one batch. The timestamp and batch window is intended to allow an honest aggregator to manage this reportbatch mapping efficiently, i.e., with minimal state between aggregate requests. Unless we can think of a better way, I think we should keep this in.
This issue is now subsumed by .
Might be worth adding an OPEN ISSUE to note the inter-batch replay attack we talked about yesterday.
Change:
RFC3339.  This field is REQUIRED for objects with "valid" in the "status" field. <del> If this field is present, then it MUST contain a URL for an order resource, such that this authorization is only valid for that resource.  If this field is absent, then the CA MUST consider this authorization valid for all orders until the authorization expires. </del> For pending authorizations, the challenges that the client can fulfill in order to prove possession of the identifier.  For final authorizations, the challenges that were used.  Each array entry

Discussion:
It is no longer necessary with the order based issuance flow that allows the server to specify which authorizations a client must satisfy to allow issuance of an order. See URL Section 7.1.4 "Authorization Objects" describes an optional "scope" field. If present it must be a URI pointing to an order and the authorization is considered to be valid only for that order. If no scope value is present it is assumed that the authorization is valid for any order. Looking back at the PR that introduced the "scope" field[0] and knowing the current state of order based issuance I'm not clear why this field is needed, or what a client could do with the scope information. Can someone clarify or should this part of the spec be removed? The server determines as a matter of policy which authorizations are required for an order and includes these in the order's array. If part of that server policy is to treat some valid authorizations as only being valid for a specific order then the server can simply not include those valid authorizations in the order's authorizations array and can instead create new pending authorizations for the client to solve. The client doesn't need to understand authorization scope it just needs to know which authorizations the server says are required and how to move these authorizations to a valid state. Since the client can't ask for specific authorizations to be used with specific orders and must react to what the server provides why is it helpful to tell a client that one of the authorizations it solved won't be used with future orders? Similarly I think the scope field interacts weirdly with pre-authorization. Are all authorization objects created with pre-authorization assumed to be global scope since they aren't associated with an order? Have any ACME clients or servers implemented order scope? Let's Encrypt/Boulder/Pebble have not. Daniel / cpu [0] - URL
Change:
4.2.7. <del> perMsgChecksumSend </del> <ins> FullChecksumSend </ins> Preference

Discussion:
Why is the name not rather something like perMsgChecksumFullSend?
Happy with a change if making this more consistent.
There are some related changes in
NAME : Did the merged PR 839 happen to address this? - If not please make a PR.
NAME PR 839 updated the name, but still found it confusing so made a PR.
See review.
I do not mind what the name is called as long as it is clear. I think the proposal looks good.
Change:
5.2.12. <del> local-address-preference </del> <ins> use-temporary-local-address </ins> <del> Enumeration Default: For Listeners and Rendezvous Connections: Stable.  For other Connections: Temporary This property specifies whether Listeners and Connections should prefer the use of temporary addresses when possible.  This is generally used to prevent linking connections over time when a stable address is not needed.  Possible values are: </del> <ins> Preference </ins> <del> Prefer the use of stable (sometimes called "permanent") local addresses </del> <ins> Avoid for Listeners and Rendezvous Connections.  Prefer for other Connections. </ins> <del> Prefer the use of temporary (sometimes called "privacy") addresses </del> <ins> This property allows the application to express a preference for the use of temporary local addresses, sometimes called "privacy" addresses RFC4941.  Temporary addresses are generally used to prevent linking connections over time when a stable address, sometimes called "permanent" address, is not needed.  Note that if an application Requires the use of temporary addresses, the resulting Connection cannot use IPv4, as temporary addresses do not exist in IPv4. </ins> 5.2.13.

Discussion:
Following the suggestion in , made Local Address Preference a Set(Preference, Enumeration), so an application can now also Require or Prohibit stable addresses. Added a sentence warning that, e.g., preferring stable AND temporary addresses does not make sense - but there are less obvious ways to produce a conflicting set of Selection Properties, too, and we know how to deal with them.
Interim discussion: let's use prohibit/avoid/prefer/require temporary addresses. Default connections to prefer temporary. Default listeners to avoid temporary.
Note that it fails without temporary addresses if you require temporary; which makes IPv4 fail.
Simplified this as discussed in the interim. Please take another look.
Looks good to me – But I am unsure whether we should replace the temporary address with a stable address with Preference. Rational: For IPv6 with outgoing connections, temporary is default anyway, so requiring the special case instead of avoid/prohibit the default looks much more straight forward.
I've read this a few times but I'm still not sure: What alternative solution are you proposing here?
I am proposing to Invert the whole name and meaning of the property – instead of requesting a temporary address, request a stable address.
Thanks for clarifying. I think this Property is straightforward enough as is, no need to invert.
For Local Address Preference we only have the option to prefer stable or temporary. However, I guess we would also need a way to e.g. specify that stable is required, no?
Is this addressed by PR ?
I don't think so.
lgtm
Change:
10. Security issues are discussed throughout this memo, especially in <del> Appendices C, D, and E. </del> <ins> Appendices B, C, and D. </ins> 11.

Discussion:
This revises "The Cipher Suites" section to simplify redundant language, actually explain the de facto naming convention, and add all currently available AEAD cipher suites. It also drops the appendix table that has already had its section whittled down quite a bit, in favor of the explanation and new table in the main section. Note that this is all of the AEAD ciphers available in the current IANA registry [0], plus ChaChaPoly (which has to be a normative reference [1], so must reach RFC status before this does). Issue just said "standards track AEAD ciphers", but as the registry lists them all, adding them wasn't difficult. If we'd rather not cite them here then they can of course be cut out (ARIA, Camellia, & ECDHE AES-CCM are informational; the rest are standards track, including DHE AES-CCM). Alternatively, the table could be annotated to note which are on what track or split in two. This has no changes to any requirements. [0] URL [1] URL
NAME I addressed your comments in this new commit. I switched to a table to make things easier to read and explicitly clarified the constant string bits so as to be more clear. I also dropped the confusing sentence fragment.
looks good.
AES-OCB will also be addable to this list, but its codepoints are all completely TBD still. URL
Rebased, squashed, & updated for recent changes to draft.
Ok, all comments addressed with that last commit. I've split the table into standards and non-standards and simplified the note to just mention ECDHE AES GCM being widely deployed.
Rebased.
Ok, reworded that bit too.
I only added the GCM AEAD ciphers. We should add all the standards track AEAD ciphers.
NAME This was dealt with in PR and can be closed.
Change:
The User Equipment can store the last response it received from the Captive Portal API as a cached view of its state within the Captive <del> Network.  This state can be used to determine whether its Captive </del> <ins> Portal.  This state can be used to determine whether its Captive </ins> Portal Session is near expiry.  For example, the User Equipment might compare a timestamp indicating when the session expires to the current time.  Storing state in this way can reduce the need for

Discussion:
A reviewer pointed out that Captive Portal and Captive Network were used interchangeably in the document. While we used Captive Network more frequently, Captive Portal aligns more closely with familiar use of the term. Further, other documents such as the API draft refer to the system as a whole as a Captive Portal, which makes this change more aligned with them.
Tirupachur Comerica, Subash writes: I think that this is clear: one is a network and the other a server. Review to see if the right choice is used throughout. URL point out that we assume a degree of mutual control over both.
Change:
OHB cannot reflect their original values, the receiver will be unable to verify the E2E integrity of the packet. <del> The OHB has the following syntax (in ABNF): </del> <ins> The OHB has the following syntax (in ABNF RFC5234): </ins> If present, the PT and SEQ parts of the OHB contain the original payload type and sequence number fields, respectively.  The final

Discussion:
NAME added few nits to the commit
Oh, one things I think we should add ref to ABNF
Change:
NO <ins> For the second interaction triggered by the above, the endpoint takes the role of a server: </ins> RD -> EP GET

Discussion:
See the linked issues. Contributes-To: URL Closes: URL
Reduced (to the point where the PR's title is no longer really accurate), amended by oversights and split up into individual commits. NAME does this look better to you now? (The paragraph on the intention of the interaction templates is not in here yet, that'll be a separate PR.)
A con= value on a simple registration may be unintuitive to implementors (they'd expect to do role reversal when fetching the .well-known/core). We could disallow it, and would just need to state its implications (namely that endpoints that do virtual hosting or that register via CoAP-over-TCP can not use simple registration). The current patch for (b26dd6678e66e68ddb3850949f398bcf3c550416) already has this effect (but not yet the caveats wording). (Brought up during plug test, see )
8 Is there supposed to be a way for simple registration to return an error message? As written this is not necessarily done. Specifically, the response to the post can be executed before the query to /.well-known/core is done and the registration is attempted. I see what you mean: also the return of 2.04 shows in the example but not in the specification. This warrants additional text to specify the simple registration text. will add the simple registration template to the text.
Added template in section 5.3.1. simple registration
Ad "GET /.well-known/core": Our templates are already verbose, redundant with CoAP ("4.00 Bad Request and 400 Bad Request: Malformed request.", surprise) and at the same time not exhaustive (see ); I've come to accept that. But the GET section on the endpoint's .well-known/core is the very functionality that is described in RFC6690 Section 4. What is gained by duplicating that specification and selectively picking some possible error codes? I suggest we remove that part. Ad simple registration interface: Any particular reason you picked precisely ep and d to be eligible? lt definitely makes sense, and so do extra-attrs (they are our extension point, and not having them would exclude simple registration from extensibility). A pull request to that respect is pending (see link below) together with .

I think that's in a good state now with , , and the separator paragraph before the GET operation in #simple. I might have missed the point of this issue though, so not closing right away; NAME please close if you think this issue is done. Hi Christian, thanks for this very useful work Some questions/ remarks below. certainly not; it beats the purpose. We may add text in RD to address the TCP part. to what purpose? It states explicitly that it is a scheme//authority string, no query parameters possible; The simplicity helps to specify an already complex subject to be filled into the github, I hope. >