Question: The term "Remote Attestation" is a common expression and often associated or connoted with certain properties.  The term "Remote" in this context does not necessarily refer to a remote entity in the <del> scope of network topologies or the Internet.  It rather refers to a decoupled system or entities that exchange the payload of the </del> <ins> scope of network topologies or the Internet.  It rather refers to decoupled systems or entities that exchange the payload of the </ins> Conceptual Message type called Evidence I-D.ietf-rats-architecture. This conveyance can also be "Local", if the Verifier role is part of the same entity as the Attester role, e.g., separate system <del> components of the same Composite Device (a single RATS entity). Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf- rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device-attest. </del> <ins> components of the same Composite Device (a single RATS entity).  Even if an entity takes on two or more different roles, the functions they provide typically reside in isolated environments that are components of the same entity.  Examples of such isolated environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf-rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device- attest. </ins> 3.

Based on URL In Section 1, 3 Disambiguation About “these types of co-located environments”, The previous sentences are about the Verifier and Attester don’t need to be remote. So “these” is weird here, because here is about the attesting environment and target environment.
So, can this issue then be closed? Hi Henk, I've reviewed the reference interaction models I-D recently, I hope the comments below can help improve the draft before the IETF110 draft submission cut-off. Section 3 Disambiguation Comment > This section is talking about the disambiguation of terminology, so I suggest making it a sub-section of Section 2 Terminology. Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)). Comment > About "these types of co-located environments", The previous sentences are about the Verifier and Attester don't need to be remote. So "these" is weird here, because here is about the attesting environment and target environment. Section 5 Direct Anonymous Attestation Comment > I think it's better to move this section to the bottom of the draft. DAA doesn't introduce a new information elements, and only augments the scope/definition of Attester Identity and Authentication Secret IDs, describing it after the introduction of all the 3 basic interaction models would be better. Putting DAA in the middle makes me feel the basic interaction models rely upon DAA, but actually it's not. This document extends the duties of the Endorser role as defined by the RATS architecture with respect to the provision of these Attester Identity documents to Attesters. The existing duties of the Endorser role and the duties of a DAA Issuer are quite similar as illustrated in the following subsections. Comment > Without DAA, I think the Endorser also needs to provision the Attester Identity to Attesters. And as I understand, the DAA Issuer is a supply chain entity before the Attester being shipped, so it is the Endorser when DAA is used, right?


Question: The term "Remote Attestation" is a common expression and often associated or connoted with certain properties.  The term "Remote" in this context does not necessarily refer to a remote entity in the <del> scope of network topologies or the Internet.  It rather refers to a decoupled system or entities that exchange the payload of the </del> <ins> scope of network topologies or the Internet.  It rather refers to decoupled systems or entities that exchange the payload of the </ins> Conceptual Message type called Evidence I-D.ietf-rats-architecture. This conveyance can also be "Local", if the Verifier role is part of the same entity as the Attester role, e.g., separate system <del> components of the same Composite Device (a single RATS entity). Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf- rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device-attest. </del> <ins> components of the same Composite Device (a single RATS entity).  Even if an entity takes on two or more different roles, the functions they provide typically reside in isolated environments that are components of the same entity.  Examples of such isolated environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf-rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device- attest. </ins> 3.

If yes, then in the next sentence, the comparison between Endorser and DAA Issuer doesn't make sense to me. Section 5.1 Endorsers Comment > Does this section have difference with the definition of Endorser in architecture draft? If not, is it necessary to keep this section? Comment > This section only describes the Layered Attestation, but the scope of Endorsement is more than what's described here. Endorsement indicates the Attester's various capabilities such as Claims collection and Evidence signing. For other situations than Layered Attestation, the Endorser and Endorsement are also needed. So why only mention Layered Attestation here? I don't see any special relationship between DAA and Layered Attestation. Section 5.2 Endorsers for Direct Anonymous Attestation In order to enable the use of DAA, an Endorser role takes on the duties of a DAA Issuer in addition to its already defined duties. DAA Issuers offer zero-knowledge proofs based on public key certificates used for a group of Attesters [DAA]. Effectively, these certificates share the semantics of Endorsements, with the following exceptions: Comment > In the first sentence, I suggest saying that "a DAA Issuer takes on the role of an Endorser". o The associated private keys are used by the DAA Issuer to provide an Attester with a credential that it can use to convince the Verifier that its Evidence is valid. To keep their anonymity the Attester randomizes this credential each time that it is used. Comment > How to understand "Evidence is valid"? Does it mean the Evidence is sent from an authentic Attester and not tampered during the conveyance? Or does it mean the Evidence comes from a RoT and is trustable (although the Evidence can diverge from the Reference Values)? Comment > When saying "Attester randomizes this credential", how many credentials does an Attester have? 1) Can a DAA Issuer have multiple key pairs and use them for one Attester? 2) Can a DAA Issuer use one key pair to generate multiple credentials for one Attester?


Question: The term "Remote Attestation" is a common expression and often associated or connoted with certain properties.  The term "Remote" in this context does not necessarily refer to a remote entity in the <del> scope of network topologies or the Internet.  It rather refers to a decoupled system or entities that exchange the payload of the </del> <ins> scope of network topologies or the Internet.  It rather refers to decoupled systems or entities that exchange the payload of the </ins> Conceptual Message type called Evidence I-D.ietf-rats-architecture. This conveyance can also be "Local", if the Verifier role is part of the same entity as the Attester role, e.g., separate system <del> components of the same Composite Device (a single RATS entity). Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf- rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device-attest. </del> <ins> components of the same Composite Device (a single RATS entity).  Even if an entity takes on two or more different roles, the functions they provide typically reside in isolated environments that are components of the same entity.  Examples of such isolated environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf-rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device- attest. </ins> 3.

o A credential is conveyed from an Endorser to an Attester in combination with the conveyance of the public key certificates from Endorser to Verifier. Comment > Is there another way to convey the public key certificate, for example, can the public key certificates be conveyed from Endorser to Attester first and then from Attester to Verifier? The zero-knowledge proofs required cannot be created by an Attester alone - like the Endorsements of RoTs - and have to be created by a trustable third entity - like an Endorser. Due to that semantic overlap, the Endorser role is augmented via the definition of DAA duties as defined below. This augmentation enables the Endorser to convey trustable third party statements both to Verifier roles and Attester roles. Comment > For "the definition of DAA duties as defined below", what is the definition of DAA duties? Comment > In the last sentence, the Endorsement with its original definition is the third party statement for Verifier and Attester, isn't it? So, "augmentation" isn't the correct expression. Section 6 Normative Prerequisites Attester Identity: The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. Comment > The Attester Identity is to identify which Attester the Evidence comes from. But if the Attester has multiple Attesting Environments, what should be the Attester Identity? Comment > The TPM's AIK certificate is one kind of Attester Identity, right? Attestation Evidence Authenticity: Attestation Evidence MUST be correct and authentic. Comment > Is it appropriate to say "correct Evidence"? If saying so, I think it means that the Evidence satisfies the Attestation Policy for Evidence. Authentication Secret: An Authentication Secret MUST be available exclusively to an Attester's Attesting Environment. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence. The Authentication Secret MUST be established before RATS can take place. Comment > Does the Authentication Secret represent the identity of the Attesting Environment? Comment > How to understand the Authentication Secret, and is it necessary all the time?


Question: The term "Remote Attestation" is a common expression and often associated or connoted with certain properties.  The term "Remote" in this context does not necessarily refer to a remote entity in the <del> scope of network topologies or the Internet.  It rather refers to a decoupled system or entities that exchange the payload of the </del> <ins> scope of network topologies or the Internet.  It rather refers to decoupled systems or entities that exchange the payload of the </ins> Conceptual Message type called Evidence I-D.ietf-rats-architecture. This conveyance can also be "Local", if the Verifier role is part of the same entity as the Attester role, e.g., separate system <del> components of the same Composite Device (a single RATS entity). Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf- rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device-attest. </del> <ins> components of the same Composite Device (a single RATS entity).  Even if an entity takes on two or more different roles, the functions they provide typically reside in isolated environments that are components of the same entity.  Examples of such isolated environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf-rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device- attest. </ins> 3.

For example, in our implementation, during the router booting up, the BIOS measures the BootLoader and records the measured hash value into the TPM, and the BootLoader measures the OS Kernel and records the measured hash value into the TPM as well. From the Layered Attestation perspective, I think (BIOS + TPM) is the Attesting Environment and (BootLoader + TPM) is also the Attesting Environment. But the Claims (measured hash values) aren't protected separately, and they finally becomes the Evidence (TPM Quote) and it's only protected by the TPM's AIK. So, what is the Authentication Secret? Section 7 Generic Information Elements Attester Identity ('attesterIdentity'): mandatory A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. Comment > Previous section says "Attester Identity" is about "a distinguishable Attesting Environment", and here says it's about "a distinguishable Attester". Comment > How to understand "without accompanying evidence about its validity"? Attester Identity ('attesterIdentity'): mandatory In DAA, the Attester's identity is not revealed to the verifier. The Attester is issued with a credential by the Endorser that is randomized and then used to anonymously confirm the validity of their evidence. The evidence is verified using the Endorser's public key. Comment > I think here means the DAA credential represents the Attester Identity. Comment > There is ambiguity of "that is randomized", does it mean randomized Endorser or randomized credential? Comment > For "confirm the validity of their evidence", what does "their" refer to? And what does "the validity of evidence" mean? Authentication Secret IDs ('authSecID'): mandatory A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Evidence. Comment > Previous section says "Authentication Secret" is used to protect Claims, but here says it's used to protect Evidence. Comment > As I understand, if Authentication Secret represents the identity of Attesting Environment, then it's not mandatory, at least in our implementation.


Question: The term "Remote Attestation" is a common expression and often associated or connoted with certain properties.  The term "Remote" in this context does not necessarily refer to a remote entity in the <del> scope of network topologies or the Internet.  It rather refers to a decoupled system or entities that exchange the payload of the </del> <ins> scope of network topologies or the Internet.  It rather refers to decoupled systems or entities that exchange the payload of the </ins> Conceptual Message type called Evidence I-D.ietf-rats-architecture. This conveyance can also be "Local", if the Verifier role is part of the same entity as the Attester role, e.g., separate system <del> components of the same Composite Device (a single RATS entity). Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf- rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device-attest. </del> <ins> components of the same Composite Device (a single RATS entity).  Even if an entity takes on two or more different roles, the functions they provide typically reside in isolated environments that are components of the same entity.  Examples of such isolated environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf-rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device- attest. </ins> 3.

Authentication Secret IDs ('authSecID'): mandatory In DAA, Authentication Secret IDs are represented by the Endorser (DAA issuer)'s public key that MUST be used to create DAA credentials for the corresponding Authentication Secrets used to protect Evidence. In DAA, an Authentication Secret ID does not identify a unique Attesting Environment but associated with a group of Attesting Environments. This is because an Attesting Environment should not be distinguishable and the DAA credential which represents the Attesting Environment is randomised each time it used. Comment > In my understanding, here says that the DAA credential identities the Attesting Environment. Compared with the description in the "Attester Identity" part, what does the DAA credential represent actually? Reference Claims ('refClaims') mandatory Reference Claims are components of Reference Values as defined in [I-D.ietf-rats-architecture]. [Editor's Note: Definition might become obsolete, if replaced by Reference Values. Is there a difference between Claims and Values here? Analogously, why is not named Reference Claims in the RATS arch?] Comment > I suggest using Reference Values to keep consistent with the RATS arch. Reference Claims are used to appraise the Claims received from an Attester via appraisal by direct comparison. Comment > "Direct comparison" isn't the correct expression, the comparison can have other rules. Claim Selection ('claimSelection'): optional A statement that represents a (sub-)set of Claims that can be created by an Attester. Claim Selections can act as filters that can specify the exact set of Claims to be included in Evidence. An Attester MAY decide whether or not to provide all Claims as requested via a Claim Selection. Comment > The "all Claims" may be ambiguous, I'd like to double check, does it refer to all Claims that the Attester can create or refer to all Claims requested in the Claim Selection? Section 8.1 Challenge/Response Remote Attestation Comment > In the sequence diagram, some elements in the bracket are not defined in the "Information Elements" section, such as targetEnvironment, collectedClaims, eventLog. Should these elements be defined? Section 9 Additional Application-Specific Requirements Depending on the use cases covered, there can be additional requirements. An exemplary subset is illustrated in this section.


Question: The term "Remote Attestation" is a common expression and often associated or connoted with certain properties.  The term "Remote" in this context does not necessarily refer to a remote entity in the <del> scope of network topologies or the Internet.  It rather refers to a decoupled system or entities that exchange the payload of the </del> <ins> scope of network topologies or the Internet.  It rather refers to decoupled systems or entities that exchange the payload of the </ins> Conceptual Message type called Evidence I-D.ietf-rats-architecture. This conveyance can also be "Local", if the Verifier role is part of the same entity as the Attester role, e.g., separate system <del> components of the same Composite Device (a single RATS entity). Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf- rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device-attest. </del> <ins> components of the same Composite Device (a single RATS entity).  Even if an entity takes on two or more different roles, the functions they provide typically reside in isolated environments that are components of the same entity.  Examples of such isolated environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf-rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device- attest. </ins> 3.

Comment > Here starts to talk about "additional requirements", but I wonder there is no other places in this draft talking about requirement, so what are the basic requirements? Regards & Thanks! Wei Pan


Question: The following values are used for L: <del> limits messages to 2^16 bytes in length.  The nonce length is 13 bytes allowing for 2^(13*8) possible values of the nonce without repeating. </del> <ins> limits messages to 2^16 bytes (64Kbyte) in length.  This sufficently long for messages in the constrainted world.  The nonce length is 13 bytes allowing for 2^(13*8) possible values of the nonce without repeating. </ins> limits messages to 2^64 byes in length.  The nonce length is 7 bytes allowing for 2^56 possible values of the nonce without

Assign integer tags to the CCM modes that we are keeping. Remove the 192-bit key CCM modes from the table. Update example using CCM


Question: Mutual TLS certificate verification <del> OAuth Demonstration of Proof-of-Possession key proof header </del> HTTP Signing signature header OAuth PoP key proof authentication header

remove OAuth DPoP binding. Described why on IETF mailing list: only works for asymmetric keys, requires key be presented in the header (duplicating information from GNAP messages). It was never meant to be a general purpose signing mechanism, though the FAPI group in OIDF is considering it as an option in current proposed work.
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: c380eb747945a8002c19de9784e86bee713951a0 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Ok that's weird (just removed some lines...), will have a look
Ok that was due to my rust analyser in vscode, fixed it now


Question: peer will retransmit in any case and therefore the ACK just allows for selective retransmission, as opposed to the whole flight retransmission in previous versions of DTLS.  For instance in the <del> flow shown in Figure 11 if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is recommended. </del> <ins> flow shown in dtls-key-update if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is recommended. </ins> The use of the ACK for the second case is mandatory for the proper functioning of the protocol.  For instance, the ACK message sent by the client in Figure 13, acknowledges receipt and processing of record 4 (containing the NewSessionTicket message) and if it is not sent the server will continue retransmission of the NewSessionTicket <del> indefinitely until its transmission cap is reached. </del> <ins> indefinitely until its maximum retransmission timemout value is reached. </ins> 8.

This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. TSV-ART Review of draft-ietf-tls-dtls13-41 Reviewer: Bernard Aboba Summary: The timeout and retransmission scheme looks workable for common cases, but could use some refinement to make it more robust. Technical Comments Handling Invalid Records Unlike TLS, DTLS is resilient in the face of invalid records (e.g., invalid formatting, length, MAC, etc.). In general, invalid records SHOULD be silently discarded, thus preserving the association; however, an error MAY be logged for diagnostic purposes. [BA] How does silent discard of invalid records interact with retransmission timers? Implementations which choose to generate an alert instead, MUST generate error alerts to avoid attacks where the attacker repeatedly probes the implementation to see how it responds to various types of error. Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service (DoS) attacks because UDP forgery is so easy. Thus, this practice is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. [BA] "this practice" refers to "generate an alert instead", correct? Timer Values Though timer values are the choice of the implementation, mishandling of the timer can lead to serious congestion problems, for example if [BA] Saying "timer values are the choice of the implementation" seems odd, because it is followed by normative language. I would delete this and start the sentence with "Mishandling...". many instances of a DTLS time out early and retransmit too quickly on a congested link.


Question: peer will retransmit in any case and therefore the ACK just allows for selective retransmission, as opposed to the whole flight retransmission in previous versions of DTLS.  For instance in the <del> flow shown in Figure 11 if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is recommended. </del> <ins> flow shown in dtls-key-update if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is recommended. </ins> The use of the ACK for the second case is mandatory for the proper functioning of the protocol.  For instance, the ACK message sent by the client in Figure 13, acknowledges receipt and processing of record 4 (containing the NewSessionTicket message) and if it is not sent the server will continue retransmission of the NewSessionTicket <del> indefinitely until its transmission cap is reached. </del> <ins> indefinitely until its maximum retransmission timemout value is reached. </ins> 8.

Implementations SHOULD use an initial timer value of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double the value at each retransmission, up to no less than 60 seconds (the RFC 6298 maximum). Application specific profiles, such as those used for the Internet of Things environment, may recommend longer timer values. Note that a 100 msec timer is recommended rather than the 3-second RFC 6298 default in order to improve latency for time- sensitive applications. Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be minimal. Implementations SHOULD retain the current timer value until a message is transmitted and acknowledged without having to be retransmitted, at which time the value may be reset to the initial value. [BA] Is it always possible to distinguish a retransmission from a late arrival of an original packet? This seems like it could result in wrongly resetting the timer in some situations. Large Flight Sizes DTLS does not have any built-in congestion control or rate control; in general this is not an issue because messages tend to be small. However, in principle, some messages - especially Certificate - can be quite large. If all the messages in a large flight are sent at once, this can result in network congestion. A better strategy is to send out only part of the flight, sending more when messages are acknowledged. DTLS offers a number of mechanisms for minimizing the size of the certificate message, including the cached information extension [RFC7924] and certificate compression [RFC8879]. [BA] How does the implementation know how much of the flight to send? Not sure how prevalent large certs are for DTLS (e.g. compared with the self-signed certs of WebRTC), but in EAP-TLS deployments, large certs have caused problems. The EAP-TLS cert document draft-ietf-emu-eaptlscert cites some additional mechanisms for reducing certificate sizes, such as draft-ietf-tls-ctls and [RFC6066] which defines the "clientcertificateurl" extension which allows TLS clients to send a sequence of Uniform Resource Locators (URLs) instead of the client certificate. Alert Messages Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake.


Question: peer will retransmit in any case and therefore the ACK just allows for selective retransmission, as opposed to the whole flight retransmission in previous versions of DTLS.  For instance in the <del> flow shown in Figure 11 if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is recommended. </del> <ins> flow shown in dtls-key-update if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is recommended. </ins> The use of the ACK for the second case is mandatory for the proper functioning of the protocol.  For instance, the ACK message sent by the client in Figure 13, acknowledges receipt and processing of record 4 (containing the NewSessionTicket message) and if it is not sent the server will continue retransmission of the NewSessionTicket <del> indefinitely until its transmission cap is reached. </del> <ins> indefinitely until its maximum retransmission timemout value is reached. </ins> 8.

However, a DTLS implementation which would ordinarily issue an alert SHOULD generate a new alert message if the offending record is received again (e.g., as a retransmitted handshake message). Implementations SHOULD detect when a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected. Note that alerts are not reliably transmitted; implementation SHOULD NOT depend on receiving alerts in order to signal errors or connection closure. [BA] For the fatal alert case, it does seem like retransmission would be a good idea; otherwise the peer can be left hanging. Section 7.1 "Disruptions" such as reordering do not affect timers, correct? ACKs SHOULD NOT be sent for these flights unless generating the responding flight takes significant time. What is "significant time"? Editorial Comments (NITs) Section 2 The reader is also as to be familiar with [BA] "as" -> "assumed" Section 3 The basic design philosophy of DTLS is to construct "TLS over datagram transport". Datagram transport does not require nor provide reliable or in-order delivery of data. The DTLS protocol preserves this property for application data. Applications such as media streaming, Internet telephony, and online gaming use datagram transport for communication due to the delay-sensitive nature of transported data. The behavior of such applications is unchanged when the DTLS protocol is used to secure communication, since the DTLS protocol does not compensate for lost or reordered data traffic. [BA] While low-latency streaming and gaming does use DTLS to protect data (e.g. for protection of WebRTC data channel), telephony and RTC Audio/Video uses DTLS/SRTP for key derivation only, and SRTP for protection of data. So you might want to make a distinction. Section 3.1 Note that timeout and retransmission do not apply to the HelloRetryRequest since this would require creating state on the server. The HelloRetryRequest is designed to be small enough that it will not itself be fragmented, thus avoiding concerns about interleaving multiple HelloRetryRequests. [BA] I would add "For more detail on timeouts and retransmission, see Section 5.8." Transport Layer Mapping DTLS messages MAY be fragmented into multiple DTLS records. Each DTLS record MUST fit within a single datagram.


Question: peer will retransmit in any case and therefore the ACK just allows for selective retransmission, as opposed to the whole flight retransmission in previous versions of DTLS.  For instance in the <del> flow shown in Figure 11 if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is recommended. </del> <ins> flow shown in dtls-key-update if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is recommended. </ins> The use of the ACK for the second case is mandatory for the proper functioning of the protocol.  For instance, the ACK message sent by the client in Figure 13, acknowledges receipt and processing of record 4 (containing the NewSessionTicket message) and if it is not sent the server will continue retransmission of the NewSessionTicket <del> indefinitely until its transmission cap is reached. </del> <ins> indefinitely until its maximum retransmission timemout value is reached. </ins> 8.

In order to avoid IP fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer. [BA] You might reference PMTU considerations described in Section 4.4. Post-handshake client authentication Messages of each category can be sent independently, and reliability is established via independent state machines each of which behaves as described in Section 5.8.1. For example, if a server sends a NewSessionTicket and a CertificateRequest message, two independent state machines will be created. As explained in the corresponding sections, sending multiple instances of messages of a given category without having completed earlier transmissions is allowed for some categories, but not for others. Specifically, a server MAY send multiple NewSessionTicket messages at once without awaiting ACKs for earlier NewSessionTicket first. Likewise, a server MAY send multiple CertificateRequest messages at once without having completed earlier client authentication requests before. In contrast, implementations MUST NOT have send KeyUpdate, NewConnectionId or RequestConnectionId [BA] "send" -> "sent" Example of Handshake with Timeout and Retransmission The following is an example of a handshake with lost packets and retransmissions. Note that the client sends an empty ACK message because it can only acknowledge Record 1 sent by the server once it has processed messages in Record 0 needed to establish epoch 2 keys, which are needed to encrypt to decrypt messages found in Record 1. [BA] "encrypt to decrypt" -> "encrypt or decrypt"? Section 7.3 In the first case the use of the ACK message is optional because the peer will retransmit in any case and therefore the ACK just allows for selective retransmission, as opposed to the whole flight retransmission in previous versions of DTLS. For instance in the flow shown in Figure 11 if the client does not send the ACK message [BA] Figure 11 is the DTLS State Machine. Are you referring to another figure? The use of the ACK for the second case is mandatory for the proper functioning of the protocol. For instance, the ACK message sent by the client in Figure 13, acknowledges receipt and processing of record 4 (containing the NewSessionTicket message) and if it is not sent the server will continue retransmission of the NewSessionTicket indefinitely until its transmission cap is reached.


Question: peer will retransmit in any case and therefore the ACK just allows for selective retransmission, as opposed to the whole flight retransmission in previous versions of DTLS.  For instance in the <del> flow shown in Figure 11 if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is recommended. </del> <ins> flow shown in dtls-key-update if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is recommended. </ins> The use of the ACK for the second case is mandatory for the proper functioning of the protocol.  For instance, the ACK message sent by the client in Figure 13, acknowledges receipt and processing of record 4 (containing the NewSessionTicket message) and if it is not sent the server will continue retransmission of the NewSessionTicket <del> indefinitely until its transmission cap is reached. </del> <ins> indefinitely until its maximum retransmission timemout value is reached. </ins> 8.

[BA] Do you mean "maximum retransmission timemout value"?
Addressed in


Question: Note: "double-quoted" strings follow the JSON string syntax (RFC8259); "single-quoted" strings follow an analogous pattern <del> (syntax-index). </del> <ins> (syntax-index).  No attempt was made to improve on this syntax, so characters with scalar values above 0x10000, such as U+0026 U+0023 U+0031 U+0032 U+0039 U+0033 U+0030 U+0030 U+003B ("🤔", AMPERSAND, NUMBER SIGN, DIGIT ONE, DIGIT TWO, DIGIT NINE, DIGIT THREE, DIGIT ZERO, DIGIT ZERO, SEMICOLON), need to be represented by a pair of surrogate escapes (""uD83EuDD14"" in this case). </ins> 2.5.1.2.

Add pair of surrogate escapes to note on string format.
LGTM, thanks. Just one editorial suggestion.


Question: process performed at the beginning of the connection SHOULD be applied for all paths used by the connection. <del> In case multiple connections share the same network path, as determined by having the same source and destination IP address and UDP ports, endpoints should try to co-ordinate across all connections to ensure a clear signal to any on-path measurement points. </del> When the spin bit is disabled, endpoints MAY set the spin bit to any value, and MUST ignore any incoming value.  It is RECOMMENDED that endpoints set the spin bit to a random value either chosen

As discussed, this is a) hard to do in all cases, b) impossible to do in many, and c) not that useful.
good
When multiple connections share the same network path or multiple connection IDs are used for the same path, using the spin bit is complicated by the difficulty in correlating forward and reverse flows. There is currently text that uses RFC 6919 language in the draft recommending coordination of the spin to avoid this problem. However, as , this coordination seems difficult and therefore unlikely. It also creates a strong signal that indicates that all the connections on the path are terminated at the same endpoint on both ends. Maybe we don't want to be generating that signal. Also, because this coordination can't be guaranteed, the on-path observer is forced to build code for correlating/segregating measurements by connection ID in the case where there is no coordination. Maybe it's best just to remove this recommendation entirely.
+1 to removing the recommendation, or changing the statement to just a caution (e.g., if you are to coalesce connections that spin, then you'd better be aware of ...). FWIW I am not sure if I agree with this observation. IIUC, the connections sharing a 5-tuple will be terminated by the same endpoint on both ends; it is impossible for a middlebox to coalesce multiple QUIC connections. It is impossible because CIDs can change mid-connection, and a middlebox cannot determine to where the packets containing the new CID must be sent.
There definitely needs to be a degree of coordination between the middlebox and the endpoints, but that doesn't mean that you can't use something like the quic-lb stuff on either end (or both ends).
Yes, I think it is better to remove that recommendation, but perhaps replace it with a note to observers.


Question: An Attester creates Evidence that is conveyed to a Verifier. The Verifier uses the Evidence, and any Endorsements from Endorsers, <del> by applying an Evidence Appraisal Policy to assess the </del> <ins> by applying an Appraisal Policy for Evidence to assess the </ins> trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Appraisal Policy for Evidence might be obtained from an Endorser along with the Endorsements, or might be

Change "Evidence Appraisal Policy" -> "Appraisal Policy for Evidence" Fixes editorial nit reported to me by Tolga Acar Signed-off-by: Dave Thaler
looks good.


Question: tls-resumption-psk shows a pair of handshakes in which the first establishes a PSK and the second uses it: <del> Note that the client supplies a ClientKeyShare to the server as well, which allows the server to decline resumption and fall back to a full handshake.  However, because the server is authenticating via a PSK, it does not send a Certificate or a CertificateVerify.  PSK-based resumption cannot be used to provide a new ServerConfiguration. </del> <ins> As the server is authenticating via a PSK, it does not send a Certificate or a CertificateVerify.  PSK-based resumption cannot be used to provide a new ServerConfiguration.  Note that the client supplies a ClientKeyShare to the server as well, which allows the server to decline resumption and fall back to a full handshake. </ins> The contents and significance of each message will be presented in detail in the following sections.

The current wording at the end of the section on resumption and PSK should be changed to indicate that if a server declines resumption then a full handshake, including the server Certificate and CertificateVerify messages, should take place. In its current state, the comment on omission of these messages is not disjoint from the statement regarding the server's rejection of resumption.


Question: 4.1. <ins> While other interference techniques outlined in this section mostly focus on blocking or preventing access to content, it can be an effective censorship strategy in some cases to not entirely block access to a given destination, or service but instead degrade the performance of the relevant network connection.  The resulting user experience for a site or service under performance degradation can be so bad that users opt to use a different site, service, or method of communication, or may not engage in communication at all if there are no alternatives.  Traffic shaping techniques that rate-limit the bandwidth available to certain types of traffic is one example of a performance degradation. Trade offs: While implementing a performance degradation will not always eliminate the ability of people to access a desire resource, it may force them to use other means of communication where censorship (or surveillance) is more easily accomplished. Empirical examples: Iran is known to shape the bandwidth available to HTTPS traffic to encourage unencrypted HTTP traffic Aryan-2012. 4.2. </ins> Packet dropping is a simple mechanism to prevent undesirable traffic. The censor identifies undesirable traffic and chooses to not properly forward any packets it sees associated with the traversing

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


Question: The next step is to generate m= sections, as specified in RFC4566 Section 5.14.  An m= section is generated for each RtpTransceiver <del> that has been added to the PeerConnection via the addTrack, addTransceiver, and setRemoteDescription methods.  [[OPEN ISSUE: move discussion of setRemoteDescription to the subsequent-offer section.]] This is done in the order that their associated RtpTransceivers were added to the PeerConnection and excludes RtpTranscievers that are stopped and not associated with an m= section (either due to an m= section being recycled or an RtpTransceiver having been stopped before being associated with an m= section) . </del> <ins> that has been added to the PeerConnection.  This is done in the order that their associated RtpTransceivers were added to the PeerConnection and excludes RtpTransceivers that are stopped and not associated with an m= section (either due to an m= section being recycled or an RtpTransceiver having been stopped before being associated with an m= section) . </ins> Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique

LGTM
WFM. NAME PTAL
The current draft suggests moving the discussion of setRemoteDescription: [[OPEN ISSUE: move discussion of setRemoteDescription to the subsequent-offer section.]]


Question: The "Deprecation" response header field describes the deprecation of the resource identified with the response it occurred within (see <del> Section 3.1.4.1 of HTTP).  It conveys either the deprecation date, which may be in the future (the resource context will be deprecated at that date) or in the past (the resource context has been deprecated at that date), or it simply flags the resource context as being deprecated. </del> <ins> Section 3.1.4.1 of HTTP).  It conveys the deprecation date, which may be in the future (the resource context will be deprecated at that date) or in the past (the resource context has been deprecated at that date). </ins> Servers MUST NOT include more than one "Deprecation" header field in the same response. <del> The date, if present, is the date when the resource was or will be deprecated.  It is in the form of an IMF-fixdate timestamp. </del> <ins> The date is the date when the resource was or will be deprecated.  It is in the form of an IMF-fixdate timestamp. </ins> The following example shows that the resource context has been deprecated on Sunday, November 11, 2018 at 23:59:59 GMT: The deprecation date can be in the future.  This means that the <del> resource will be deprecated at the given date in future. If the deprecation date is not known, the header field can carry the simple string "true", indicating that the resource context is deprecated, without indicating when that happened: </del> <ins> resource will be deprecated at the indicated date in the future. </ins> 2.2.

Looks good to me.
... are considered a 'bad smell'. Instead of a date vs. a fixed string, could we just say that a date in the past is equal to 'true'?
i guess we could. and we already say that a date in the past means that the resource is deprecated. the motivation to allow a flag was to not force services to make up a date when they don't have one and simply want to flag something as deprecated. but we could also "force" them to make up a date by not allowing the "true" flag. i am fine either way and i do see the point that the syntax may cause some implementations to not parse the field correctly. maybe others can weigh in as well?
FWIW, I see it like Expires -- if it's already stale, you just assign a date in the past.
i could definitely live with such a design.
One use case was to align the header's usage with API contract as defined using OpenAPI. Having boolean helps align this header with OpenAPI's flag which does not require date. Forcing API developers to add a random date in the past in case if it is not available due toe various reasons would not be desirable for various other reasons (SLA?). Although, I wish that OpenAPI adds date for . >If the deprecation date is not known, the header field can carry the simple string "true", indicating that the resource context is deprecated, without indicating when that happened: On Jul 31, 2021, at 06:46, Mark Nottingham NAME wrote: FWIW, I see it like Expires -- if it's already stale, you just assign a date in the past.
For Expires, January 1 1970 (epoch 0) is widely used.
NAME I wish OpenAPI supported deprecated date also. But when we do, it won't be with a property that can be boolean or date.
Ok NAME thanks for clarification on the OpenAPI side of things. I agree. We can just use date. There are some implementations out there, I would not know if any of those use boolean but since we are not an RFC yet, such a change should not be unexpected.
it seems like we can safely remove the alternative syntax. i have created a PR asking for review by NAME
LGTM


Question: HTTP message content after the headers. Note that use of the Capsule Protocol is not required to use HTTP <del> Datagrams.  If a new HTTP Method or Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Methods or of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol.  However, new HTTP Method or Upgrade Tokens SHOULD use the Capsule Protocol unless they have a good reason not to. </del> <ins> Datagrams.  If a new HTTP Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol. However, new HTTP Upgrade Tokens that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </ins> 4.1. <del> Definitions of new HTTP Methods or of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </del> <ins> Definitions of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </ins> A variable-length integer indicating the Type of the capsule. Endpoints that receive a capsule with an unknown Capsule Type MUST

This may be answered and I just missed it. After reading I think that for HTTP/1 and HTTP/2 Datagrams (via capsules) can only be sent for new methods/upgrade tokens. But it wasn't clear to me if that same property was true for HTTP/3. For example, would it be valid to send HTTP/3 datagrams along with a GET request? If so, I think this means that for HTTP/3 a GET request could have both a body AND datagrams?
That's a very good point. If anything, we should be prescriptive about what endpoints do if they receive a datagram associated with an existing method like GET. I suspect drop or error are the most likely candidates here.
I vote for close the connection with error. The datagram has the relate to something in the request. If the request doesn't or cannot articulate a datagram use, the sender of datagram is probably broken or stupid.
Since datagrams are strongly associated with a stream, I think it'd be more consistent to make this a stream error. Regardless, folks my want an extension to GET that allows sending datagrams with it, but it makes sense to require that this extension be negotiated via headers or settings first, so the semantics of such datagrams are agreed upon beforehand. So, I'm supportive of making this a stream error, with the understanding that any extension can lift this requirement between consenting parties.
I'd prefer to make people suffer but I could live with a stream error. Like you suggest, by letting people people agree on a change of requirements, we support extension. But the default of erroring helps datagram avoid the mess othat GET with body is.
Also, I reserve the right to count the number of these failures and close the connection if it reaches my annoyance threshold
Ah yes . Sounds good, I'll write up a PR for this once the design team PRs are landed.
Sounds good to me. An extension could just as easily lift a connection error requirement as it could a stream error requirement in case that had any bearing on the thinking here. (A connection error might be nice because it prevents a confused peer from sending a possibly incessant stream of datagrams.


Question: HTTP message content after the headers. Note that use of the Capsule Protocol is not required to use HTTP <del> Datagrams.  If a new HTTP Method or Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Methods or of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol.  However, new HTTP Method or Upgrade Tokens SHOULD use the Capsule Protocol unless they have a good reason not to. </del> <ins> Datagrams.  If a new HTTP Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol. However, new HTTP Upgrade Tokens that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </ins> 4.1. <del> Definitions of new HTTP Methods or of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </del> <ins> Definitions of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </ins> A variable-length integer indicating the Type of the capsule. Endpoints that receive a capsule with an unknown Capsule Type MUST

On the other hand, confused peers gonna be confused and David's point about datagrams being strongly associated with a request is a good point)
I think it should be a stream error to enable method-agnostic gateways and proxies, which may be multiplexing different clients' traffic onto a single next-hop connection.
In , NAME points out that Content-Type doesn't make sense with the capsule protocol. Should we prohibit it?
In , NAME points out that status codes 204, 205, and 206 don't make sense with the capsule protocol. Should we prohibit them?
The spec currently says: In HTTP/1.x, the message content is generally delineated by the Content-Length header field or the Transfer-Encoding; another request can follow on the same connection. One of the (many) ways in which CONNECT and Upgrade are special is that in H1 it takes over the connection and makes the request extend to the end of the connection, preventing any further requests from being made. The description attempts to be generic about method, but implicitly assumes an indefinite length stream of bytes which (in H1) is only true of CONNECT or Upgrade. This concept is correct for what we have in mind, but the boundaries aren't crisply described right now. NAME may have opinions.
The sentence right after the bit you pasted is: That constrains this to CONNECT/Upgrade/new methods. Is that not enough?
I think "new methods" is probably the most questionable. It's not clear to me that a new method can obtain the special behaviors of CONNECT. If it were restricted to upgrade tokens (whether with HTTP/1.1 Upgrade or RFC 8441 Extended CONNECT), I think that would address the concern.
I believe what he means is this definition of a data stream only holds for CONNECT requests. There is no mechanism to extend that to new request methods since all other methods are required to have length-delimited data (or no data).
Likewise, I don't know of any reason we would want to support such extension methods in the future, since that is a known failure point for CONNECT. It is far simpler for a new method to require chunked or data frames.
Restricting this to extended CONNECT and Upgrade sounds reasonable to me
For Upgrade, the new protocol takes over after the current response is complete. Hence, the description above doesn't really work for Upgrade either.


Question: HTTP message content after the headers. Note that use of the Capsule Protocol is not required to use HTTP <del> Datagrams.  If a new HTTP Method or Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Methods or of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol.  However, new HTTP Method or Upgrade Tokens SHOULD use the Capsule Protocol unless they have a good reason not to. </del> <ins> Datagrams.  If a new HTTP Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol. However, new HTTP Upgrade Tokens that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </ins> 4.1. <del> Definitions of new HTTP Methods or of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </del> <ins> Definitions of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </ins> A variable-length integer indicating the Type of the capsule. Endpoints that receive a capsule with an unknown Capsule Type MUST

NAME the intent of that text was to mean "after the current response is complete" - do you have a proposal for phrasing that would work better?
Semantics says: URL I think is consistent with the definition of "data stream" in this document. (And in fact uses the term "data stream" without defining it.) That doesn't seem to match deferring the new protocol until after the response.
I don't think there is any technical distinction between the two descriptions; it's nomenclature to say that what follows the CONNECT is a tunnel ended by connection closure, whereas what follows Upgrade is a different protocol that might very well come back to this one (as determined by the other protocol).
And point to URL This is an important part of the security analysis.
Only if you believe that the Sec- prefix is useful for the Capsule-Protocol header field. I don't.
Sorry, I don't mean that it's the only thing that makes it work, merely that if were going to talk about how to analyze it, this is something we should say.
NAME can you clarify your intent? Your issue title starts with "Add to JS" but I suspect you didn't mean that we should modify the JavaScript specification. Would a note next to where the "Capsule-Protocol" header is defined resolve this?
Aaargh. I meant "add to the security considerations".
Thanks, that makes more sense :) Adding something to security considerations sounds good to me, I'll add text to the . Note that this was filed on the wrong repository, is the droid you're looking for.
So this assumption is useful in that it helps us avoid an analysis. Though my sense is that that analysis isn't especially difficult. The header field exists to enable datagram forwarding behaviour in an intermediary. We only have to show that there is no harm inflicted if a client engages that behaviour for requests, under the constraint that the client is otherwise authorized to make from a web context. The risk comes if this forwarding behaviour somehow generates different semantics as a result. As the same client also provides the stream of data that will be forwarded, it is trivial to see that they are already in a position to engage whatever semantics they choose.


Question: HTTP message content after the headers. Note that use of the Capsule Protocol is not required to use HTTP <del> Datagrams.  If a new HTTP Method or Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Methods or of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol.  However, new HTTP Method or Upgrade Tokens SHOULD use the Capsule Protocol unless they have a good reason not to. </del> <ins> Datagrams.  If a new HTTP Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol. However, new HTTP Upgrade Tokens that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </ins> 4.1. <del> Definitions of new HTTP Methods or of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </del> <ins> Definitions of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </ins> A variable-length integer indicating the Type of the capsule. Endpoints that receive a capsule with an unknown Capsule Type MUST

The only scenario that might benefit an attacker is where the elision of datagrams (or things that look like them) might be used to evade security protections that scan the stream of data. For an attack to be effective, those same protections would have to be ignorant of datagram forwarding behaviour at the same intermediary. This binding to CONNECT is a useful shortcut that means we don't need to engage with all that stuff, which wouldn't be that easy to write down. (This aversion to engagement is, I believe, a large part of why people want to slap "Sec-" on all new headers.)
MT's framing of this is helpful. Adding some security consideration about what might go wrong for an intermediary seems potentially useful. Spending text on why a browser is special in this regard seems less compelling to nme.
I was about to write a PR for this, but I think we should first If we decide that capsules are only allowed for HTTP upgrade tokens (and not new methods) then we've restricted ourselves to CONNECT and Upgrade which are both inaccessible from JavaScript.
LGTM thanks


Question: probes the implementation to see how it responds to various types of error.  Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service <del> (DoS) attacks because UDP forgery is so easy.  Thus, this practice is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </del> <ins> (DoS) attacks because UDP forgery is so easy.  Thus, the practice of generating fatal alerts is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </ins> If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts


Question: probes the implementation to see how it responds to various types of error.  Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service <del> (DoS) attacks because UDP forgery is so easy.  Thus, this practice is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </del> <ins> (DoS) attacks because UDP forgery is so easy.  Thus, the practice of generating fatal alerts is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </ins> If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts


Question: probes the implementation to see how it responds to various types of error.  Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service <del> (DoS) attacks because UDP forgery is so easy.  Thus, this practice is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </del> <ins> (DoS) attacks because UDP forgery is so easy.  Thus, the practice of generating fatal alerts is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </ins> If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts


Question: probes the implementation to see how it responds to various types of error.  Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service <del> (DoS) attacks because UDP forgery is so easy.  Thus, this practice is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </del> <ins> (DoS) attacks because UDP forgery is so easy.  Thus, the practice of generating fatal alerts is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </ins> If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts


Question: probes the implementation to see how it responds to various types of error.  Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service <del> (DoS) attacks because UDP forgery is so easy.  Thus, this practice is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </del> <ins> (DoS) attacks because UDP forgery is so easy.  Thus, the practice of generating fatal alerts is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </ins> If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts


Question: will typically be the minimum of the server's self-imposed limit and TicketRequestContents.count. <del> Servers that support ticket requests MUST NOT echo "ticket_request" in the EncryptedExtensions message.  A client MUST abort the connection with an "illegal_parameter" alert if the "ticket_request" extension is present in the EncryptedExtensions message. </del> <ins> A server that supports ticket requests MAY echo the "ticket_request" extension in the EncryptedExtensions message.  If present, it contains a TicketRequestContents structure, where TicketRequestContents.count indicates the number of tickets the server expects to send to the client. Servers MUST NOT send the "ticket_request" extension in ServerHello or HelloRetryRequest messages.  A client MUST abort the connection with an "illegal_parameter" alert if the "ticket_request" extension is present in either of these messages. </ins> If a client receives a HelloRetryRequest, the presence (or absence) of the "ticket_request" extension MUST be maintained in the second

Addresses and . The server hint came up in the context of QUIC, e.g., as a possible optimization to let clients know if they should expect any post handshake messages. cc NAME NAME
Looks like this got merged without any business days to review it :) but otherwise the text looks good, approved.
Every day is a business day! ;-)
From NAME
Fixed by .
You probably want to be clear that ticket_request cannot appear in HRR, given that you have a section on it.
Fixed in .
I'm not a huge fan of sending extensions that aren't really needed, but this seems fine. I missed the QUIC discussion (or maybe it's still in my inbox). BTW, I still like the idea of hoisting tickets to the application layer, but ekr seems to think that they belong at the TLS layer. I guess we'll just have to keep disagreeing on that point :)


Question: Claims about a root of trust typically are asserted by Endorsers. The device illustrated in layered includes (A) a BIOS stored in read- <del> only memory, (B) an updatable bootloader, and (C) an operating system kernel. </del> <ins> only memory, (B) an operating system kernel, and (C) an application or workload. </ins> Attesting Environment A, the read-only BIOS in this example, has to ensure the integrity of the bootloader (Target Environment B).  There

` The loader environment only exists for a second or two, and has few resources… how it is supposed to report evidence to a verifier in that window?
Refers to figure 3, in section 3.4, on layered attestation.
It is rare that early layers generate or convey Evidence. In critical system with appropriate protected capabilities that actually happens. I can see that it is not a common case and would not argue strongly against removing 'B' from that conveyance arc.
Perhaps a better example for which the loader environment is not ephemeral would be where B is the OS and C is an application/workload process.


Question: Implementations MUST either abandon an association or re-key prior to allowing the sequence number to wrap. <del> Implementations MUST NOT allow the epoch to wrap, but instead MUST establish a new association, terminating the old association. </del> 4.2.2. When receiving protected DTLS records, the recipient does not have a full epoch or sequence number value in the record and so there is <del> some opportunity for ambiguity.  Because the full epoch and sequence number are used to compute the per-record nonce, failure to reconstruct these values leads to failure to deprotect the record, and so implementations MAY use a mechanism of their choice to determine the full values.  This section provides an algorithm which is comparatively simple and which implementations are RECOMMENDED to follow. </del> <ins> some opportunity for ambiguity.  Because the full sequence number is used to compute the per-record nonce and the epoch determines the keys, failure to reconstruct these values leads to failure to deprotect the record, and so implementations MAY use a mechanism of their choice to determine the full values.  This section provides an algorithm which is comparatively simple and which implementations are RECOMMENDED to follow. </ins> If the epoch bits match those of the current epoch, then implementations SHOULD reconstruct the sequence number by computing

Yet another attempt to This builds on Chris's PR but just omits the epoch entirely from the AEAD nonce calculation. This is more consistent with TLS and doesn't require special case reasoning about why we only need to build in the bottom 16 bits. This relies entirely on the keys being different. Needs analysis.
This seems promising.
NAME this LGTM, but there's a conflict. Can you resolve prior to merging? NAME are you OK with the new rationale, and text that allows it to be relaxed in the future?
If I have understood and calculated correctly DTLS 1.3 limits the number of packets in a AES-GCM connection to 2^40.5 compared to 2^64 in DTLS 1.2. This is quite a severe limitation that is not mentioned explicitly. The AEAD limits in themselves are not a problem, but the combination of AEAD limits (2^24.5) and a small epoch (2^16) is a problem. I think this is major problem in some use cases of DTLS. E.g. most 3GPP 5G use cases where DTLS or DTLS/SCTP is used for semi-permanent connections (lasting years) and where the terminating the connection cause severe disturbances. I did not find any discussion about this problem (but I could easily have missed it) It is known that the limit of 2^48 packets in SRTP can be reached and 2^40.5 is significantly smaller than this... If the document was not in such a late stage, I would have suggested to increase the size of the epoch to 32 bits..... I think this and the other problems DTLS 1.3 has with semi-permanent connections has to be solved sooner than later.
NAME thanks for filing this. I hear you about the late stage, but IIRC we never represent the entire epoch on the wire in any case, so it seems like just changing it to 32 bits would be pretty easy, so why not do it now?
How do the chacha20 numbers compare to the AES-GCM ones?


Question: Implementations MUST either abandon an association or re-key prior to allowing the sequence number to wrap. <del> Implementations MUST NOT allow the epoch to wrap, but instead MUST establish a new association, terminating the old association. </del> 4.2.2. When receiving protected DTLS records, the recipient does not have a full epoch or sequence number value in the record and so there is <del> some opportunity for ambiguity.  Because the full epoch and sequence number are used to compute the per-record nonce, failure to reconstruct these values leads to failure to deprotect the record, and so implementations MAY use a mechanism of their choice to determine the full values.  This section provides an algorithm which is comparatively simple and which implementations are RECOMMENDED to follow. </del> <ins> some opportunity for ambiguity.  Because the full sequence number is used to compute the per-record nonce and the epoch determines the keys, failure to reconstruct these values leads to failure to deprotect the record, and so implementations MAY use a mechanism of their choice to determine the full values.  This section provides an algorithm which is comparatively simple and which implementations are RECOMMENDED to follow. </ins> If the epoch bits match those of the current epoch, then implementations SHOULD reconstruct the sequence number by computing

NAME I don't think (D)TLS 1.3 puts any limits on ChaCha20 so my understanding is understanding is that the total number of packets can be protected in the current drafts is ChaCha20 2^64 (2^48 2^16) AES-GCM 2^40.5 (2^24.5 2^16) AES-GCM 2^39 (2^23 * 2^16)
NAME I am all for changing this now. I made a PR that change epoch from uint16 to uint32. As you say, it seems like a pretty easy change to do. Is uint32 the right size?
Unless you think we should do uint64. NAME NAME what would we have to do to make this change?
URL Magnus Westerlund thinks uint64 would be a safer bet.Michael Tüxen suggest to wrap the uint16 epoch instead. That might be an easier solution. I don't see a direct problem in DTLSPlaintext, ACK message, or recordsequencenumber with a uint16 epoch that is allowed to wrap like: 4, 5, ... 2^16-1, 4, 5, ... 2^16-1, 4, 5, ...
NAME NAME NAME since it's through the IESG we would need to at least raise that this change was made after they had approved it. I suspect that doing some kind of 2-week heads up to the WG/IESG that we want to make the change before landing it. But, if we do that or something more drastic that's really up to NAME
I want to point out that allowing wrapping per may not be the best solution if one considers to use the DTLS epoch as part of the input to the TLS exporter as suggested in . Then one want an input that doesn't wrap, and then to ensure that one doesn't practically run into any limits, then an uint64 would be better. An unit32 appears to be sufficient for a quite extreme use case with minimal messages size (which is one DTLS record with 4 byte user message) and high bandwidth (10 Gbps) sustained over a period of more than 5 years before the epoch would wrap.


Question: Implementations MUST either abandon an association or re-key prior to allowing the sequence number to wrap. <del> Implementations MUST NOT allow the epoch to wrap, but instead MUST establish a new association, terminating the old association. </del> 4.2.2. When receiving protected DTLS records, the recipient does not have a full epoch or sequence number value in the record and so there is <del> some opportunity for ambiguity.  Because the full epoch and sequence number are used to compute the per-record nonce, failure to reconstruct these values leads to failure to deprotect the record, and so implementations MAY use a mechanism of their choice to determine the full values.  This section provides an algorithm which is comparatively simple and which implementations are RECOMMENDED to follow. </del> <ins> some opportunity for ambiguity.  Because the full sequence number is used to compute the per-record nonce and the epoch determines the keys, failure to reconstruct these values leads to failure to deprotect the record, and so implementations MAY use a mechanism of their choice to determine the full values.  This section provides an algorithm which is comparatively simple and which implementations are RECOMMENDED to follow. </ins> If the epoch bits match those of the current epoch, then implementations SHOULD reconstruct the sequence number by computing

However, to my understanding the full epoch value are so rarely included in transmitted DTLS messages that its size have minimal implication on the overhead that it is not worth saving 4-bytes to be certain to have eliminated any practical limitation.
I think a 2-week WGLC and notifying the IESG will suffice.
FYI. We have now run into quite many problems with the interworking of semi-permanent DTLS/SCTP connections (lasting years) and DTLS 1.3: No Diffie-Hellman rekeying No post-handshake server authentication No rekeying of the exporter_secret 2^40.5 packets limit 2 minute MSL requirement 2^38.5 byte SCTP user message size limit Our initial plan was to just replace DTLS 1.2 with DTLS 1.3, leave DTLS/SCTP as is, but as the problems keep adding up we are now startnig to consider quite big changes to DTLS/SCTP 1.3 to make this work: URL Using new DTLS connections instead of KeyUpdate could potentially address the first five, but is a significant change.
Hi, Based on the problems long-lived DTLS/SCTP had with DTLS 1.3 (as well as DTLS 1.2 without renegotiation and respecting AEAD limits) we restructured DTLS/SCTP (RFC6083bis) to use parallel connections instead of relying on renegotiation and post-handshake messages. We think this quite easily solves all the problems we had without requiring any updates of DTLS 1.3. It also makes DTLS/SCTP less dependant on version specific DTLS mechanisms. It will hopefully work without changes with any future DTLS 1.4. URL We can now firmly RECOMMEND DTLS 1.3 which I think is very important. 5G is to a large degree replacing or complementing IPsec with TLS, DTLS, and DTLS/SCTP. I will do my best to transition 3GPP to DTLS 1.3 asap. FYI, 3GPP DTLS/SCTP associations have very long lifetimes (can be years), strive for five nines (99.999%) availability and cannot be teared down without causing major disruptions.


Question: Implementations MUST either abandon an association or re-key prior to allowing the sequence number to wrap. <del> Implementations MUST NOT allow the epoch to wrap, but instead MUST establish a new association, terminating the old association. </del> 4.2.2. When receiving protected DTLS records, the recipient does not have a full epoch or sequence number value in the record and so there is <del> some opportunity for ambiguity.  Because the full epoch and sequence number are used to compute the per-record nonce, failure to reconstruct these values leads to failure to deprotect the record, and so implementations MAY use a mechanism of their choice to determine the full values.  This section provides an algorithm which is comparatively simple and which implementations are RECOMMENDED to follow. </del> <ins> some opportunity for ambiguity.  Because the full sequence number is used to compute the per-record nonce and the epoch determines the keys, failure to reconstruct these values leads to failure to deprotect the record, and so implementations MAY use a mechanism of their choice to determine the full values.  This section provides an algorithm which is comparatively simple and which implementations are RECOMMENDED to follow. </ins> If the epoch bits match those of the current epoch, then implementations SHOULD reconstruct the sequence number by computing

With such long lifetimes we think mutual reauthentication, rekeying of the SCTP-AUTH key, and forcing attackers to dynamic key exfiltration [RFC7624] are required features. I still think should be done. 2^40.5 packets is quite limiting.
Seems OK.Thanks -- this LGTM. We'll need to do a brief consensus call given the type of change.


Question: 6.5.1. SHOULD include a "Date" header field in Encapsulated Requests, unless <del> the does not use "Date" for anti-replay purposes. </del> <ins> the has prior knowledge that indicates that the does not use "Date" for anti-replay purposes. </ins> Though HTTP requests often do not include a "Date" header field, the value of this field might be used by a server to limit the amount of

Comment by NAME In How does a client know this? Preconfiguration ? Are we talking ms? sec? minutes? Any advise to implementers ?
It can't be less than 2s, because the granularity of the field doesn't permit detecting anything finer than 1s. I've done what I can.
This still does not seem to address: Maybe just cut off the “unless” part if there is no signal for this? Paul
NAME also included URL which I think should address your concern:
Thanks. That commit does address the issue, mostly. I guess it moves it do an unspecified provisioning layer :P Paul


Question: 9.8. <del> IANA has added the media type "application/edhoc" to the "Media Types" registry. </del> <ins> IANA has added the media types "application/edhoc+cbor-seq" and "application/cid-edhoc+cbor-seq" to the "Media Types" registry. 9.8.1. </ins> Type name: application <del> Subtype name: edhoc </del> <ins> Subtype name: edhoc+cbor-seq </ins> Required parameters: N/A

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


Question: 13. <del> During the gathering phase of ICE (sec-gathering) and while ICE is performing connectivity checks (sec-connectivity_check), an agent sends STUN and TURN transactions.  These transactions are paced at a rate of one every Ta milliseconds, and utilize a specific RTO.  This section describes how the values of Ta and RTO are computed.  This computation depends on whether ICE is being used with a real-time media stream (such as RTP) or something else.  When ICE is used for a stream with a known maximum bandwidth, the computation in sec-rtp- based MAY be followed to rate-control the ICE exchanges.  For all other streams, the computation in sec-non-rtp MUST be followed. </del> 13.1. <del> The values of RTO and Ta change during the lifetime of ICE processing.  One set of values applies during the gathering phase, and the other, for connectivity checks. The value of Ta SHOULD be configurable, and SHOULD have a default of: where k is the number of media streams.  During the gathering phase, Ta is computed based on the number of media streams the agent has indicated in the candidate information, and the RTP packet size and RTP ptime are those of the most preferred codec for each media stream.  Once the candidate exchange is completed, the agent recomputes Ta to pace the connectivity checks.  In that case, the value of Ta is based on the number of media streams that will actually be used in the session, and the RTP packet size and RTP ptime are those of the most preferred codec with which the agent will send. In addition, the retransmission timer for the STUN transactions, RTO, defined in RFC5389, SHOULD be configurable and during the gathering phase, SHOULD have a default of: where the number of pairs refers to the number of pairs of candidates with STUN or TURN servers. For connectivity checks, RTO SHOULD be configurable and SHOULD have a default of: where Num-Waiting is the number of checks in the check list in the Waiting state, and Num-In-Progress is the number of checks in the In- Progress state.  Note that the RTO will be different for each transaction as the number of checks in the Waiting and In-Progress states change. These formulas are aimed at causing STUN transactions to be paced at the same rate as media.  This ensures that ICE will work properly under the same network conditions needed to support the media as well.  See sec-pacing for additional discussion and motivations. Because of this pacing, it will take a certain amount of time to obtain all of the server reflexive and relayed candidates. Implementations should be aware of the time required to do this, and if the application requires a time budget, limit the number of candidates that are gathered. The formulas result in a behavior whereby an agent will send its first packet for every single connectivity check before performing a retransmit.  This can be seen in the formulas for the RTO (which represents the retransmit interval).  Those formulas scale with N, the number of checks to be performed.  As a result of this, ICE maintains a nicely constant rate, but becomes more sensitive to </del> <ins> During the ICE gathering phase (sec-gathering) and while ICE is performing connectivity checks (sec-connectivity_check), an agent triggers STUN and TURN transactions.  These transactions are paced at a rate indicated by Ta, and the retransmission interval for each transaction is calculated based on the the retransmission timer for the STUN transactions (RTO) RFC5389. This section describes how the Ta and RTO values are computed during the ICE gathering pahse and while ICE is performing connectivity checks. NOTE: Previously, in RFC 5245, different formulas were defined for comupting Ta and RTO, depending on whether ICE was used for a real- time media stream (e.g.  RTP) or not. The formulas below result in a behavior whereby an agent will send its first packet for every single connectivity check before performing a retransmit.  This can be seen in the formulas for the RTO (which represents the retransmit interval).  Those formulas scale with N, the number of checks to be performed.  As a result of this, ICE maintains a nicely constant rate, but becomes more sensitive to </ins> packet loss.  The loss of the first single packet for any connectivity check is likely to cause that pair to take a long time to be validated, and instead, a lower-priority check (but one for

Ta and RTO settings are now the same for real-time media and non-real-time media. An appendix has been added, showing bandwidth consumption based on different values, and different ufrag value sizes.


Question: 9.1. <ins> IANA has created a new registry titled "EDHOC Exporter Label" under the new heading "EDHOC".  The registration procedure is "Expert Review".  The columns of the registry are Label, Description, and Reference.  All columns are text strings.  The initial contents of the registry are: 9.2. </ins> IANA has created a new registry titled "EDHOC Cipher Suites" under the new heading "EDHOC".  The registration procedure is "Expert Review".  The columns of the registry are Value, Array, Description, and Reference, where Value is an integer and the other columns are text strings.  The initial contents of the registry are: <del> 9.2. </del> <ins> 9.3. </ins> IANA has created a new registry entitled "EDHOC Method Type" under the new heading "EDHOC".  The registration procedure is "Expert

(Last two commits on wrong branch.)
The prototype of EDHOC-Exporter() has remained EDHOC-Exporter(label, length), while it should be EDHOC-Exporter(label, context, length) as per Alternative 3 discussed in issue URL Correct?
Thanks NAME your comment is addressed in the latest commit. I merge this now.
The text use both the terms "session" and "protocol instance", would be good to settle for one term.
Just chose one, I don't think this needs an issue
In the security considerations "session" makes most sense to me. There is also the term "connection". I will make a proposal.
The spec should likely forbid multiple calls to the EDHOC-Exporter interface with the same label, in order to prevent the same key being reused. Discussed with NAME and NAME
Good catch. Yes, we should have some text about that, but it should probably more be a requirement on the application using EDHOC that on EDHOC itself. Two different application should defintly not use the same label. The same application might rederive the same key several times as long as it keep track of its AEAD nonces and replay window. I thought that we had already IANA registry proposed for this, but that is not the case. We should probably have one. If we have a IANA registry the labels get more fixed and it might be that we need a context input parameter as well.
If we make a IANA registrer for labels, I think we need to let the application add additional information in some way. Two alternatives: We make an IANA register for label prefixes, and let the application append information to the label prefix. This was recently planned for EAP-TLS (and methods built on EAP-TLS) but was changes because the TLS export labels are not really ment to be labels. This would not change the current exporter interface. We expand the interface with a context parameter. This is similar to the TLS exporter. A problem with the TLS exporter is that some implementations decided to not even support context.
NAME how is the context parameter intended to be used? Could you give an example? Would this be some sort of "salt" when deriving the key?
Don't register labels, register label prefixes.


Question: 9.1. <ins> IANA has created a new registry titled "EDHOC Exporter Label" under the new heading "EDHOC".  The registration procedure is "Expert Review".  The columns of the registry are Label, Description, and Reference.  All columns are text strings.  The initial contents of the registry are: 9.2. </ins> IANA has created a new registry titled "EDHOC Cipher Suites" under the new heading "EDHOC".  The registration procedure is "Expert Review".  The columns of the registry are Value, Array, Description, and Reference, where Value is an integer and the other columns are text strings.  The initial contents of the registry are: <del> 9.2. </del> <ins> 9.3. </ins> IANA has created a new registry entitled "EDHOC Method Type" under the new heading "EDHOC".  The registration procedure is "Expert

The motivation for "context" or "label postfixes" is to increase the flexibility for the application. Restricting the application to IANA registered labels is very limiting. An application might want to use the EDHOC exporter to derive a number of keys and we should encourage that. The alternative is that the application needs to implement its own key derivation, which might be less secure and might be outside of the TEE. I called it "context" just because TLS calls the paramater in its exporter context.
"Be like TLS" is of course a good motivation. Technically, a label prefix is not different from a context, it just saves the need to separate prefix and suffix.
(And of course there is nothing wrong with multiple calls with the same label; the application has a "right to forget" :-)
The solutions should be equal when it comes to security. The choice should be made based on what is easiest for implementators and apllications using EDHOC. Alt 1. We make an IANA register for label prefixes: "OSCORE Master Secret" "OSCORE Master Salt" The Export function stays the same: EDHOC-Exporter(label, length) = EDHOC-KDF(PRK4x3m, TH4, label, length) An application is allowed to append things to the label prefix: "OSCORE Master Secret" "OSCORE Master Secret PickleRick" Alt 2. We make an IANA register for labels: label = "OSCORE Master Secret" label = "OSCORE Master Salt" The Export function needs to change: EDHOC-Exporter(label, ctx, length) = EDHOC-KDF(PRK4x3m, TH4, [label, ctx] , length) An application is not allowed to append things to the label and uses the ctx instead: label = "OSCORE Master Secret" ctx = "" label = "OSCORE Master Secret" ctx = "PickleRick"
No major opinion. Alt 2 breaks the test vector for the OSCORE security context. It would be good to get more input.
Any preference NAME NAME NAME ?
If desired the CTX is more convenient it can always be added in a wrapper on top of EDHOC-Exporter(). (I assume re-use of label+ctx in Alt 2 is equivalent to re-use of label in Alt 1?)
I prefer to have explicitly specified.