jiebi/CodeConvo huggingface dataset:
Code change:
before or during Connection establishment, see also msg- safelyreplayable.  It is given in Bytes. <del> 7.1.10.2. </del> <ins> 7.1.11.2. </ins> singularTransmissionMsgMaxLen

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

Related discussion:
text: I have no opinion on Gorry's comment, but I'm a bit mystified by the "shouldn't be in the API doc" argument. Perhaps I'm not understanding the purpose of taps-interface? I thought it was a qualitative description of the controls offered to the application, which this clearly would be!
I would define taps as an interface to control network connections. So flushing state is a good thing in some scenarios for privacy but not really needed to handle network connections.
See also -- this surfaced that we have drifted on connection group versus context, which we need to fix in arch.
Martin to write a PR against API to propose a context API that would provide the intent of this functionality. Alternative is to NOP this in the API doc ("connection contexts are too implementation specific to expose in a general way" or similar)
A second alternative is a one-bit fix: a selection property that requires a given connection to be in a separate connection context (which implies a separate connection group) from other connections created in the preconnection.
A very nice approach IMO, thanks for doing thisI like this approach for the simplicity, but it still solves only half of the problem we have with connection groups vs. connection contexts. I am fine with merging this, but IMHO it does not fully Thanks NAME looks good to me now.
Code change:
Pass AD_2 to the security application. <del> If any verification step fails, the Initiator MUST send an EDHOC error message back, formatted as defined in error, and the protocol MUST be discontinued. </del> <ins> If any processing step fails, the Initiator SHOULD send an EDHOC error message back, formatted as defined in error.  Sending error messages is essential for debugging but MAY e.g.be skipped if a session cannot be found or due to denial of service reasons, see security.  If an error message is sent, the session MUST be discontinued. </ins> 5.5.

Related discussion:
text: Looks good.
The current draft has the following text in several places: "If any verification step fails, the Responder MUST send an EDHOC error message back, formatted as defined in {{error}}, and the protocol MUST be discontinued." I am not sure this is a good idea. This means that the availability of EDHOC will be low. An attacker can e.g. send a single byte as message_4 and it would make EDHOC shut down imidiatly. I think we need to soften this and give the implementation some more choice here. Are there constrained radio protocols where noice could be mistaken for an actual message and forwarded to EDHOC or do all constrained radio have strong enough CRC to make sure that that more or less never happens?
I just changed the following text OLD: If the Initiator previously received from the Responder an error message with error code 1 (see Section 6.3) indicating cipher suites supported by the Responder which also are supported by the Initiator, then the Initiator SHALL select the most preferred cipher suite of those. NEW: If the Initiator previously received from the Responder an error message with error code 1 (see Section 6.3) indicating cipher suites supported by the Responder which also are supported by the Initiator, then the Initiator SHOULD select the most preferred cipher suite of those (note that error messages are not authenticated and may be forged). Made me think about that I don't think the group has discussed if some error messages should be authenticated. Some error messages to message2 could include a MAC to prove that the error was sent by the same party that sent message3. error messages to message3 and message4 could be authenticated. I am uncertain if this is worth specifying. At least not as long as there are easier ways to an attacker to end the protocol. I think what needs to be done is to specify that a processing error does not need to discontinue the protocol, the received message can have been an attack. receiveing an error does not need to discontinue the protocol, the received error can have been an attack.
Code change:
Pass AD_2 to the security application. <del> If any verification step fails, the Initiator MUST send an EDHOC error message back, formatted as defined in error, and the protocol MUST be discontinued. </del> <ins> If any processing step fails, the Initiator SHOULD send an EDHOC error message back, formatted as defined in error.  Sending error messages is essential for debugging but MAY e.g.be skipped if a session cannot be found or due to denial of service reasons, see security.  If an error message is sent, the session MUST be discontinued. </ins> 5.5.

Related discussion:
text: from 20210422 interim: CB perhaps wisely said: "Use cases exist for multiplexing over same port/URI, so applications should normally sort/demultiplex traffic before start interpreting as EDHOC, which implies treating invalid messages that get to EDHOC code as an error or attack"
Yes, my understanding is that we only need to be concerned about attacks where an attacker sends a packet crafted so that it will be processed by EDHOC (which is not hard).
I made a pull request addressing this issue Added text on demultiplexing. Changed procession so implementation are not mandated to shut down the session if an attacker sends a few bytes to the EDHOC resource / port.. Added more security consideration on Denial of service.
Writing this PR made me think about whether we want to mandate that error messages are always fatal as well as downgrade protection. The ""Wrong selected cipher suite" error is fatal because it is sent in repsponse to message1. You could consider similar types of error sent in response to message2 and message3. E.g. IDCRED format not supported or CRED format not supported or X.509 public key algorithm not supported. [BBFGKZ16] defines the following theoretical downgrade protection for a session: The cryptographic parameters should be the same on both sides and should be the same as if the peers had been communicating in the absence of an attack. But this definition has very little to do with practical security. In practice it does not matter if an attacker can influence the chosen parameter in the current session or a following session. I am still confused regarding the purpose of the applicability statement. Is it a informal section describing things the parties need to both support to make the protocol work or is a normative security section relevant for policy and downgrade. If we want downgrade protection over multiple sessions, the parties need to agree or securely negotiate everything. Downgrade protection for a session does not make much sense to me if an attacker can force the parties to set up a second session with lower security.
Do we need to align the terminology, we use both "session" and "instance" in the draft?
Yes, I just changed "protocol" to "session" not remembering that the draft use instance in other places.
We can resolve this later, I opened . Unless there are other comments we will soon merge this.
The PR has been discussed and merged.
Code change:
Pass AD_2 to the security application. <del> If any verification step fails, the Initiator MUST send an EDHOC error message back, formatted as defined in error, and the protocol MUST be discontinued. </del> <ins> If any processing step fails, the Initiator SHOULD send an EDHOC error message back, formatted as defined in error.  Sending error messages is essential for debugging but MAY e.g.be skipped if a session cannot be found or due to denial of service reasons, see security.  If an error message is sent, the session MUST be discontinued. </ins> 5.5.

Related discussion:
text: Closing
Current specification mandates sending error messages upon certain failures. But in cases when message processing fails when no state has been allocated or when no connection identifier has been found or then a more appropriate action would be to just silently drop the message.
I think the MUST (if possible) is good. Debugging without any error messages is not nice. We now other protocols that it is good to mandate error messages. It is kind of obvious that can not send an error if you don't now where/how to send it. Don't know if that has to be pointed out....
Migth be good to not sent error if you are under a DoS attack.
This issue is addressed by pull request that also address availability
The PR has been discussed and merged. Closing
Code change:
The client's stream terminated without containing a fully-formed request. <ins> An HTTP message was malformed and cannot be processed. </ins> The TCP connection established in response to a CONNECT request was reset or abnormally closed.

Related discussion:
text: if we want to do that. There was a hole in the error code space, so I filled it with this. I haven't pulled Push out to its own error; it doesn't seem like it belongs with this one.
We might want to add a mention of this in A.4 where we talk about PROTOCOL_ERROR
(I couldn't find anything on this, but I'm prepared to be corrected. Also, it's late, so if this is closed, I'm totally OK with that.) We're just in the process of doing full validation of pseudo-header fields (I know, seems late, what are you gonna do about that). And we realized that there is no error code for indicating this sort of error. That is, if pseudo-fields are out of order, or a request contains , or there are uppercase characters. contains lots of MUSTs, but it seems to rely entirely on the definition of "malformed" which leads to H3GENERALPROTOCOL_ERROR. This is fine, but not especially helpful in isolating problems. Could we define an error code for this specific case?
H2 just says malformed is treated as PROTOCOL_ERROR. So H3 is providing parity. There might be an argument for more fidelity but I'm not convinced it would help much. It could require more contortions in the text - do you have different error for different types of malformed?
Internally, we use a different error code. Of course, all internal error codes map to the same code for sending in RESETSTREAM/CONNECTIONCLOSE.
I'm inclined not to do much, if anything, here. They all trace back to "malformed," as you note, which leads to GENERALPROTOCOLERROR. The instances in which we use GPE are: Malformed HTTP messages Push whose request headers change across multiple promises As a substitute for more specific codes I wouldn't be opposed to splitting the first two off into a new / two new codes, because that would be consistent with our principle of indicating the general area where the failure occurred. I would push back on having separate error codes for specific ways the message could be malformed, because that's pretty expansive rabbit hole.
OK, I'm satisfied with that response. I think that we'll just have to signal extra information in the text field. Happy to close this.
Code change:
The client's stream terminated without containing a fully-formed request. <ins> An HTTP message was malformed and cannot be processed. </ins> The TCP connection established in response to a CONNECT request was reset or abnormally closed.

Related discussion:
text: NAME do you think an error code for "malformed message" would be useful, if we don't go into the various types of malformed?
That might be useful, yes.
This is a design change, albeit a marginal one.
NAME let's merge the associated PR but keep this issue open and marked as "call-issued"
Keeping open, as requested.
Closing this now that the IESG review of draft 33 has concluded.
In fairness, I question whether the IESG review of the HTTP drafts has concluded. But as this is not an IESG comment, I'm content to close it. People have had time to object.
Yes I agree Mike. This was due to me being over eager with the close button. The issue may not have strictly been raised in the period that the IESG were directed to review the doc, and they have yet to ballot on draft 33. But either way there was no push back from the WG on this change since draft 33 was published.
Code change:
described in Section 2.1 of RFC5116.  The key is either the client_write_key or the server_write_key. The type field is identical to TLSPlaintext.type. The version field is identical to TLSPlaintext.version. The length (in bytes) of the following TLSCiphertext.fragment. The length MUST NOT exceed 2^14 + 2048. The AEAD encrypted form of TLSPlaintext.fragment. Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD operation is constructed, and what is the length of the <del> GenericAEADCipher.nonce_explicit part.  In many cases, it is appropriate to use the partially implicit nonce technique described in Section 3.2.1 of RFC5116; with record_iv_length being the length of the explicit part.  In this case, the implicit part SHOULD be derived from key_block as client_write_iv and server_write_iv (as described in key-calculation), and the explicit part is included in </del> <ins> TLSCiphertext.nonce_explicit part.  In many cases, it is appropriate to use the partially implicit nonce technique described in Section 3.2.1 of RFC5116; with record_iv_length being the length of the explicit part.  In this case, the implicit part SHOULD be derived from key_block as client_write_iv and server_write_iv (as described in key-calculation), and the explicit part is included in </ins> GenericAEAEDCipher.nonce_explicit. The plaintext is the TLSPlaintext.fragment.

Related discussion:
text: The draft was in a sort of halfway state between whether TLSCiphertext has a fragment that is a selection or just embedding the AEAD elements directly. This should normalize it to the embedded view without the extra GenericAEADCipher struct definition. (i don't think this changes the logic of the draft at all)
Code change:
Otherwise, resolve the candidate using mDNS. <del> If it resolves to an IP address, replace the value of the ICE host candidate by the resolved IP address and continue processing of the candidate. </del> <ins> If it resolves to an IP address, replace the mDNS hostname of the ICE candidate with the resolved IP address and continue processing of the candidate. </ins> Otherwise, ignore the candidate.

Related discussion:
text: PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?
Code change:
DNS: The MAC covers the account key, and the MAC key is derived from an ECDH public key signed with the account private key. <del> Proof of possession of a prior key: The signature by the prior key covers the account public key. </del> The association of challenges to identifiers is typically done by requiring the client to perform some action that only someone who effectively controls the identifier can perform.  For the challenges

Related discussion:
text: There has been no implementer interest in the proof-of-possession challenge, and it makes the document more complex by having a completely different structure than the other challenges. If it is decided later that such a challenge is necessary, it can be added in a follow-on extension specificiation.
Generally this seems fine, and I wholeheartedly agree with the purpose of the removal (for now). One problem I can't open a comment for: Line 2099, the last paragraph before "Preventing Authorization Hijacking", still refers to the PoP Challenge. Without the PoP Challenge wording, a new reader may take that this to be referring to the implicit Proof of Possession of the ACME Account Key and thus be confused. Since it's non-normative, perhaps you could simply modify that paragraph into something more like:
Code change:
"Connection Priority" on one Connection does not change it on the other Connections in the same Connection Group. <ins> The optional "connectionProperties" parameter allows passing Transport Properties that control the behavior of the underlying stream or connection to be created, e.g., protocol-specific properties to request specific stream IDs for SCTP or QUIC. </ins> Message Properties set on a Connection also apply only to that Connection.

Related discussion:
text: Does this make sense outside of a protocol-specific context? I am aware that this is a different can of worms adding protocol specific parameters to clone, but this looks like a strange concept to add an Integer here that may have different side effects in QUIC and SCTP…
That's a very good question. This feature request came up in the QuIC mapping part of the discussion in Vienna, see: URL Not sure what to do: keep it as it is, remove it, or add the protocol: assign: "if protocol = x, then stream ID = y" read: "stream ID is y, and your protocol is x" I have to say, I don't like this particular way, as it would complicate matters quite a bit. But how else to do it?
All of the multistreaming protocols we know about have an integer stream identifier. I suppose a future protocol could use some sort of binary blob for identifying streams (which are... pedantically... representable as arbitrary-length integers)
Interim discussion: let's make Clone() and Initiate() take a group of protocol-specific parameters (optionally) which allow protocols like QUIC and SCTP to extend this.
I just made a very minimalist update, where "protocolSpecificProperties" is only a parameter of Clone(). Why not list it as readable properties, and why not as a parameter of Initiate, as we discussed? What's the point of saying "there can be protocol-specific properties which are currently not defined, and they can be readable"? This is for a future spec to say, when it proposes a new transport property. Regarding Initiate(), I think this should in fact not be a parameter to the Initiate Action itself, but a transport property to be supplied when creating a Preconnection. Again, this made me find that I would only write something like "There can also be transport properties that are not yet defined", which doesn't seem to be useful text. In conclusion, I found that only the Clone() Action needs this as a new parameter. Everything else is for future mapping documents. Thoughts?
Many thanks! I incorporated your suggestion, and made a tiny edit to it (behaviour => behavior, underlaying => underlying, and "stream or connection" instead of "stream/connection").
... combined with "if the transport is mux'ing, else ..."
Thanks – I guess we have a fairly good solution.
Code change:
Before a TLS ciphersuite can be used with QUIC, a header protection algorithm MUST be specified for the AEAD used with that ciphersuite. This document defines algorithms for AEAD_AES_128_GCM, <del> AEAD_AES_128_CCM, AEAD_AES_256_GCM, AEAD_AES_256_CCM (all AES AEADs are defined in AEAD), and AEAD_CHACHA20_POLY1305 CHACHA.  Prior to TLS selecting a ciphersuite, AES header protection is used (hp-aes), matching the AEAD_AES_128_GCM packet protection. </del> <ins> AEAD_AES_128_CCM, AEAD_AES_256_GCM (all AES AEADs are defined in AEAD), and AEAD_CHACHA20_POLY1305 CHACHA.  Prior to TLS selecting a ciphersuite, AES header protection is used (hp-aes), matching the AEAD_AES_128_GCM packet protection. </ins> 5.4.2.

Related discussion:
text: draft-ietf-quic-tls currently mentions AEADAES256CCM, however there is no way to use that AEAD in TLS 1.3 - TLSAES256CCMSHA256 does not appear in the . If I understand this correctly, the presence of AEADAES256CCM in the document was an editorial oversight.
Thanks. This was extremely confusing: you meant CCM, but wrote GCM in tons of places.
Code change:
Connection Properties: The Connection Properties are used to configure protocol-specific options and control per-connection <del> behavior of the Transport System; for example, a protocol-specific Connection Property can express that if UDP is used, the implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine the selection of paths or protocols, but can be used in this way by an implementation during connection establishment.  Connection Properties are specified on a Preconnection prior to Connection establishment, and can be modified on the Connection later. Changes made to Connection Properties after Connection establishment take effect on a best-effort basis. </del> <ins> behavior of the Transport Services system; for example, a protocol-specific Connection Property can express that if UDP is used, the implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine the selection of paths or protocols, but can be used in this way by an implementation during connection establishment.  Connection Properties are specified on a Preconnection prior to Connection establishment, and can be modified on the Connection later.  Changes made to Connection Properties after Connection establishment take effect on a best- effort basis. </ins> 4.1.3.

Related discussion:
text: Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!