jiebi/CodeConvo huggingface dataset:
Change:
Can you NAME review (and Karl)?
... since 9048 did not obsolete 5448
That is is good question. I changed "updates" from RFC 5448 to RFC 9048 as the document do not even mention RFC 5448 except in the Acknowledgments. Updating increases visability and makes it easier to find the EAP-AKA'-FS document. If it updates 5448 some more mentioning of 5448 would be needed in the introduction
Closing, fix merged to the document.

Discussion:
essential zero-trust principles. This specification updates RFC 9048, the EAP-AKA' authentication <del> method, with an optional extension.  The extension, when negotiated, provides Forward Secrecy for the session key generated as a part of the authentication run in EAP-AKA'.  This prevents an attacker who has gained access to the long-term pre-shared secret in a SIM card from being able to decrypt any past communications.  In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions.  This forces attackers to use active attacks instead. </del> <ins> method, with an optional extension.  Similarly, this specification also updates the earlier version of the EAP-AKA' specification in RFC 5448.  The extension, when negotiated, provides Forward Secrecy for the session key generated as a part of the authentication run in EAP- AKA'.  This prevents an attacker who has gained access to the long- term pre-shared secret in a SIM card from being able to decrypt any past communications.  In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions.  This forces attackers to use active attacks instead. </ins> 1.
Change:
I'm flying later today and unsure about how much I can do on Monday. I will need to deploy this change and submit the draft.
ATKDF carries the legacy KDF value for those EAP peers that cannot or do not want to use this extension. Gives the impression that ATKDF is ignored when ATKDFFS is used... Gives the impression that they are used together... The Specification is clear on how to derive keys when ATKDF in {1} and ATKDF_FS in {1,2} but does not give any descriptions on how other combinations are supposed to work.
I don't know how this is supposed to work but there are several options for how they are used together. ATKDF is completely ignored when ATKDFFS is used. ATKDF determines how to derive MK, Kaut, Kre ATKDFFS determines how to derive MKECDHE, Kre, MSK, EMSK Like 2. but the PRF used in deriving MKECDHE is determined by ATKDF.
Reasons that this need to be specified is. If someone specifies ATKDF = 2. How would that work with EAP-AKA' FS If someone wants to specify a PQC KEM for ATKDF_FS. Exactly what should they specify.
Ok this seems like a fair issues. Thanks for spotting this.
I see two options. Either we are (a) trying to be clever and split what impacts what (MK, K_aut) vs. everything else or (b) we only specify a specific combination (KDF=1 + FS=1 or 2) and explicitly say that future specs need to specify how new KDF or FS algorithms can be combined with others. Both have some drawbacks ... not sure we always want to have the same split in option a. And option b leaves out a lot of room for future extensions to forget to do this. Maybe go for option b? I will try to make a PR.
I am fine with b. The PR should make clear that this updates RFC 9048 with this new requirement.
Ok
A PR has been proposed: URL
Solved per the PR so that I can submit the draft (may not be able to work on Monday due to travel).

Discussion:
generation function, if the Forward Secrecy extension is taken into use.  It will also at the same time indicate the used or desired ECDHE group.  A new attribute is needed to carry this information, as <del> AT_KDF carries the legacy KDF value which is still used together with the forward secrecy KDF value.  The legacy KDF value is also used by </del> <ins> AT_KDF carries the basic KDF value which is still used together with the forward secrecy KDF value.  The basic KDF value is also used by </ins> those EAP peers that cannot or do not want to use this extension. <ins> This specification only specifies the behaviour relating to the following combinations of basic KDF values and forward secrecy KDF values: The basic KDF value in AT_KDF is 1, as specified in RFC5448 and RFC9048, and the forward secrecy KDF values in AT_KDF_FS are 1 or 2, as specified below and in kdf2. Any future specifications that add either new basic KDF or new forward secrecy KDF values need to specify how they are treated and what combinations are allowed.  This requirement is an update to how RFC5448 and RFC9048 may be extended in the future. </ins> The format of the AT_KDF_FS attribute is shown below. The fields are as follows:
Change:
This opens up questions in URL Closes: URL
Like OSCOAP asked that new options declare themselves E or U, the HTTP mapping document asked for clarification what a cross proxy should do. Looks like both Repeat and Request-Tag are never expressed in HTTP, and that a cross proxy needs to repeat the request or run an operation with a Request-Tag just as a CoAP client; a CH proxy (CoAP server) needs to use its own discretion on when to ask for a Repeat.

Discussion:
echo-state to minimize the memory impact of having many unanswered Echo responses. <ins> CoAP-CoAP proxies MUST relay the Echo option unmodified, and SHOULD NOT cache responses when a Echo option is present in request or response for more than the exchange.  CoAP-HTTP proxies MAY request freshness, especially if they have reason to assume that access may require it (eg. because it is a PUT or POST); how this is determined is out of scope for this document.  HTTP-CoAP-Proxies SHOULD respond to Echo challenges themselves, as they know that the HTTP request is fresh, and can not forward the option anyway. </ins> 2.3. Actuation requests often require freshness guarantees to avoid
Change:
Clarifications based on Jim's review. "t0 is the time when the Echo option value was generated." "If the server cannot verify that the Echo option value was generated by the server or the round-trip time is not below the threshold the request is not processed further, and an error message MAY be sent. The error message SHOULD include a new Echo option."

Discussion:
that the Echo option value was generated by the server; otherwise the request is not processed further.  The server MUST then calculate the round-trip time RTT = (t1 - t0), where t1 is the request receive time <del> and t0 is the transmit time of the response that included the specific Echo option value.  The server MUST only accept requests with a round-trip time below a certain threshold T, i.e. RTT < T, otherwise the request is not processed further, and an error message MAY be sent.  The threshold T is application specific, its value </del> <ins> and t0 is the time when the Echo option value was generated.  The server MUST only accept requests with a round-trip time below a certain threshold T, i.e. RTT < T.  If the server cannot verify that the Echo option value was generated by the server or the round-trip time is not below the threshold the request is not processed further, and an error message MAY be sent.  The error message SHOULD include a new Echo option.  The threshold T is application specific, its value </ins> depends e.g. on the freshness requirements of the request.  An example message flow is illustrated in echo-figure.
Change:
"AEAD keys" -> "traffic keys" In (D)TLS, the algorithms may be other types than AEAD. "thus mitigating error cases and attacks where the client may erroneously associate the wrong response to a request." Some more text about this in the intro, the current text was very barebone.

Discussion:
The document also updates the processing requirements on the Token. The updated processing ensures secure binding of responses to <del> requests. </del> <ins> requests, thus mitigating error cases and attacks where the client may erroneously associate the wrong response to a request. </ins> 1.1.

When CoAP is used with a security protocol not providing bindings between requests and responses, the client MUST NOT reuse tokens <del> until the AEAD keys have been replaced.  The easiest way to </del> <ins> until the traffic keys have been replaced.  The easiest way to </ins> accomplish this is to implement the Token as a counter, this approach SHOULD be followed.
Change:
Changes in response to Carsten's comments Disposition: Will merge soon if nobody objects.
Updated to match the changes to master

Discussion:
sending messages without Request-Tag options whenever possible, and using short values when the absent option can not be recycled. <ins> The Request-Tag options MAY be present in request messages that carry a Block2 option even if those messages are not part of a blockwise request operation (this is to allow the operation described in simpleproxy).  The Request-Tag option MUST NOT be present in response messages, and MUST NOT be present if neither the Block1 nor the Block2 option is present. </ins> 3.4. 3.4.1.
Change:
"the encoding of the sequence number has to be chosen . . ." Replace "has to" with "MUST"? (I merged now and proposed the commit in the master branch)
I had to resolve a conflict before merging. Hope I did that right.

Discussion:
importance.  The client MUST make sure that tokens are not used in a way so that responses risk being associated with the wrong request. One easy way to accomplish this is to implement the Token (or part of <del> the Token) as a sequence number for each connection, starting at zero and reset to zero after rekeying, this approach SHOULD be followed. To avoid collisions the sequence number can be encoded with a fixed length or with some length-value encoding. </del> <ins> the Token) as a sequence number starting at zero for each new or rekeyed secure connection, this approach SHOULD be followed. </ins> 6.

exhaustion attacks.  One way to minimize state is to use the Integrity Protected Timestamp method described in echo-state. <ins> When the Token (or part of the Token) contains a sequence number, the encoding of the sequence number has to be chosen in a way to avoid any collisions.  This is especially true when the Token contains more information than just the sequence number (e.g. serialized state). </ins> 7. Implementations SHOULD NOT put any privacy sensitive information in
Change:
This is my take on , pointing to the cases when it's possible to reuse tokens, at the same time discouraging it for all other cases. The acceptable cases are the ones identified in the last authors' call, and TLS and OSCORE I've added in a potential third case in source comments; it's still something we can dig up if people ask for more comprehensive exceptions, but there's so many things that can go wrong that I'd rather not have it in.
Thanks, merged. I did put in a clarification on the f81c97221a1f0e7571ad06811a8b713659741336 edit -- acutally both CON and NON would be unusable.
I tried to add security considerations for token reuse to the PR. Please review, this is not trivial. Token reuse for DTLS seem hard if not impossible to do securely. I don't find Token reuse with DTLS possible to do securely..... am I missing something? Token reuse for TLS without Observer and without Groups communication seems quite easy. Do we need to say something about Group communication? Do we need to say something about stateless tokens? I think the current requirements on integrity protection and replay protection protection in the stateless draft should be enough.
I think John refers to e49ff36
Taken care of in the version -07

Discussion:
the original request was never retransmitted, <del> the response was piggybacked in an Acknowledgement message (a confirmable response may have been transmitted multiple times), and </del> <ins> the response was piggybacked in an Acknowledgement message (as a confirmable or non-confirmable response may have been transmitted multiple times), and </ins> if observation was used, the same holds for the registration, all re-registrations, and the cancellation.
Change:
Closes: URL The numeric part is trivial, the security implications (the use case for short Echo values has a different threat model than what's previously in seccons) is not.
As previously discussed in private mail: For the OSCORE state recovery use case, putting a new sequence number in the Echo option is good enough, and that can be short.

Discussion:
5. The availability of a secure pseudorandom number generator and truly <del> random seeds are essential for the security of the Echo option.  If no true random number generator is available, a truly random seed must be provided from an external source.  As each pseudoranom number must only be used once, an implementation need to get a new truly random seed after reboot, or continously store state in nonvolatile memory, see (RFC8613, Appendix B.1.1) for issues and solution approaches for writing to nonvolatile memory. </del> <ins> random seeds are essential for the security of the Echo option (except when using counting Echo values).  If no true random number generator is available, a truly random seed must be provided from an external source.  As each pseudoranom number must only be used once, an implementation need to get a new truly random seed after reboot, or continously store state in nonvolatile memory, see (RFC8613, Appendix B.1.1) for issues and solution approaches for writing to nonvolatile memory. </ins> A single active Echo value with 64 (pseudo-)random bits gives the same theoretical security level as a 64-bit MAC (as used in e.g. <del> AES_128_CCM_8).  The Echo option value MUST contain 32 (pseudo-)random bits that are not predictable for any other party than the server, and SHOULD contain 64 (pseudo-)random bits.  A server MAY use different security levels for different uses cases (client aliveness, request freshness, state synchronization, network address reachability, etc.). </del> <ins> AES_128_CCM_8).  Unless a counting Echo value is used, the Echo option value MUST contain 32 (pseudo-)random bits that are not predictable for any other party than the server, and SHOULD contain 64 (pseudo-)random bits.  A server MAY use different security levels for different uses cases (client aliveness, request freshness, state synchronization, network address reachability, etc.). </ins> The security provided by the Echo and Request-Tag options depends on the security protocol used.  CoAP and HTTP proxies require (D)TLS to

that all intermediaries are fully trusted and have not been compromised. <ins> Counting Echo values can only be used to show freshness relative to numbered events, and are the legitimate case for Echo values shorter than four bytes, which are not necessarily secret.  They MUST only be used when the request Echo values are integrity protected. </ins> Servers SHOULD use a monotonic clock to generate timestamps and compute round-trip times.  Use of non-monotonic clocks is not secure as the server will accept expired Echo option values if the clock is
Change:
Closes: URL Not tagging any of you for reviewers because that's a topic that primarily I was active on, but still not merging right away in case you want to chime in.
In the response to URL I promised better wording for the 152 bytes -- but let's see whether anything gets back there first. As Carsten pointed out, this is the derived number from the "three times" part, also accounting for the remainder of the UDP packet. Assuming an attacker wants to maximize the amplification possible by the factor 3, they will send 14 octets Ethernet header 40 octets IP header 8 octets UDP header 4 octets CoAP header 8 octets of token allowsing the server to send Σ 3 = 222 octets. Subtracting everything in the response including the UDP header, that gives 160 octets of UDP data. Given the token is variable length data of up to 8 octets the server implementer can't easily take into account, that leaves 152 octets. (Granted, that last step doesn't follow from the wording, and I'm looing to sharpen that). Having some hard number there (and I'm happy to use better ways to come up with one) is important because for generic server applications, the transports may not be known and the implementer would have to make assumptions; we can't do much more, but at least ours get solid review.
In the course of this, we'll also have to give a citation for the "x 3" (currently URL)
Follow-up note to be factored into the resolution:

Discussion:
requests immediately to have a cached result available when the client's Echoed request arrives. <del> Amplification mitigation should be used when the response would be more than three times the size of the request, considering the complete frame on the wire as it is typically sent across the Internet.  In practice, this allows UDP data of at least 152 Bytes without further checks. </del> <ins> Amplification mitigation is a trade-off between giving leverage to an attacker and causing overheads.  An amplification factor of 3 (i.e., don't send more than three times the number of bytes received until the peer's address is confirmed) is considered acceptable for unconstrained applications I-D.ietf- quic-transport. When that limit is applied and no further context is available, a safe default is sending initial responses no larger than 136 Bytes in CoAP serialization.  (The number is assuming a 14 + 40 + 8 Bytes Ethernet, IP and UDP header with 4 Bytes added for the CoAP header.  Triple that minus the non-CoAP headers gives the 136 Bytes).  Given the token also takes up space in the request, responding with 132 Bytes after the token is safe as well. </ins> When an Echo response is sent to mitigate amplification, it MUST be sent as a piggybacked or Non-confirmable response,
Change:
Closes: URL The text is a mixture of the suggestions of .
From Ines' Genart review: NAME and NAME do you know of established references we could use there to avoid rolling our own definition?
Hi, Googling a bit, I think we might need to define this ourselves. Found some papers and presentations taking about freshness, but they did not define it well. Found a very mathematical definition in some other paper that we do not want to use. I suggest something like this: Freshness is a measure of the time since time since the message was sent. What is considered a fresh message is application dependent. The Echo mechanism specified in this document allow a server to calculate an upper bound for when the message was encrypted. With this bound, the server can either verify that the message is fresh (fresher than some application defined limit) or determine that it cannot be verified that the message is fresh. Cheers, John
Maybe we can slim that down and avoid talking of time too much (because yes it's time even in the event-based case, but a very odd discrete time, so might confuse people): Would that work for you?

Discussion:
client" is used in this document to denote the client from which a request originates; to distinguish from clients in proxies. <ins> A message's "freshness" is a measure of when a message was sent on a time scale of the recipient.  A server that receives a request can either verify that the request is fresh or determine that it cannot be verified that the request is fresh.  What is considered a fresh message is application dependent; examplary uses are "no more than one hour ago" or "after this server's last reboot". </ins> The terms "payload" and "body" of a message are used as in RFC7959. The complete interchange of a request and a response body is called a (REST) "operation".  An operation fragmented using RFC7959 is called
Change:
I think it make sense to make a subsection
This is only mentioned in Abstract and intro. I think it need there needs to be some text in the body as well. The other Update has it's own subsection. "4.2. Updated Token Processing Requirements for Clients"
I added text on server requirements in
updated with one more commit: Shorten amplification-mitigateion-recommendation paragraph, align text The "RECOMMENDED" wording is removed from the description of the mechanism (it was under-explained there, the new section does it right, and there's no need to make readers wonder about updating at this point) Reference updated simplified (we're already talking about server side in the paragraph) Comment about moving text here removed, and replaced with a more precise reference I've toyed with moved text, but it rips the use cases up to the point where we'd have to re-do all the items as subsections for consistency. ... and merging (comments still appreciated, but I need the branches consolidated for futher editing)
(... and that comment should have gone to ... anyway)
Some reformulations in febc426. I think this is ready to close.
Has long been ready, and recently gotten a more explicit cross-reference too.

Discussion:
A server that sends large responses to unauthenticated peers SHOULD mitigate amplification attacks such as described in Section 11.3 of RFC7252 (where an attacker would put a victim's <del> address in the source address of a CoAP request).  The RECOMMENDED way to do this is to ask a client to Echo its request to verify its source address.  This needs to be done only once per peer and limits the range of potential victims from the general Internet to endpoints that have been previously in contact with the server. For this application, the Echo option can be used in messages that are not integrity protected, for example during discovery. </del> <ins> address in the source address of a CoAP request).  A new way to do this is to ask a client to Echo its request to verify its source address.  This needs to be done only once per peer and limits the range of potential victims from the general Internet to endpoints that have been previously in contact with the server.  For this application, the Echo option can be used in messages that are not integrity protected, for example during discovery. </ins> In the presence of a proxy, a server will not be able to distinguish different origin client endpoints.  Following from

deployment with hop-by-hop security and proxies, the server can only verify aliveness of the closest proxy. <ins> 2.5. This section updates the amplification mitigation requirements for servers in RFC7252 to recommend use of the Echo option to mitigate amplification attacks.  The requirements for clients are not updated. Section 11.3 of RFC7252 is updated by adding the following text: A CoAP server SHOULD mitigate potential amplification attacks by responding to unauthenticated clients with 4.01 Unauthorized including an Echo option, as described in echo-app item 3 of [[this document]]. </ins> 3. 3.1.
Change:
This addresses . I don't think we need to include names for the intermediary hashes.

Discussion:
Choose a connection identifier C_R and store it for the length of the protocol. <del> Compute the transcript hash TH_2 = H(message_1, data_2) where H() is the hash function in the selected cipher suite.  The transcript hash TH_2 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence. </del> <ins> Compute the transcript hash TH_2 = H( H(message_1), data_2 ) where H() is the hash function in the selected cipher suite.  The transcript hash TH_2 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence.  Note that H(message_1) can be computed and cached alredy in the processing of message_1. </ins> Compute an inner COSE_Encrypt0 as defined in Section 5.3 of I- D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in

If corr (METHOD_CORR mod 4) equals 2 or 3, C_R is omitted, otherwise C_R is not omitted. <del> Compute the transcript hash TH_3 = H(TH_2 , CIPHERTEXT_2, data_3) where H() is the hash function in the selected cipher suite.  The transcript hash TH_3 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence. </del> <ins> Compute the transcript hash TH_3 = H( H(TH_2, CIPHERTEXT_2), data_3 ) where H() is the hash function in the selected cipher suite.  The transcript hash TH_3 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence.  Note that H(TH_2, CIPHERTEXT_2) can be computed and cached alredy in the processing of message_2. </ins> Compute an inner COSE_Encrypt0 as defined in Section 5.3 of I- D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in