Question:
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:

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


Question:
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:

uses Packet Dropping as the mechanisms for throttling SSH Aryan-2012. These are but two examples of a ubiquitous censorship practice. <del> 4.2. </del> <ins> 4.3. </ins> Packet injection, generally, refers to a man-in-the-middle (MITM) network interference technique that spoofs packets in an established


Question:
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:

interference is especially evident in the interruption of encrypted/ obfuscated protocols, such as those used by Tor Winter-2012. <del> 4.3. </del> <ins> 4.4. </ins> There are a variety of mechanisms that censors can use to block or filter access to content by altering responses from the DNS


Question:
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:

TLDs as well, but only Iran has acted by blocking all Israeli (.il) domains Albert-2011. <del> 4.4. </del> <ins> 4.5. </ins> Distributed Denial of Service attacks are a common attack mechanism used by "hacktivists" and black-hat hackers, but censors have used


Question:
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:

comandeered those user agents to send DDoS traffic to various sites Marczak-2015. <del> 4.5. </del> <ins> 4.6. </ins> While it is perhaps the crudest of all censorship techniques, there is no more effective way of making sure undesirable information isn't


Question:
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:

can be physically seized or the hosting provider can be required to prevent access Anderson-2011. <ins> 6.4. In some countries, legal mechanisms exist where an individual can issue a legal request to a content host that requires the host to take down content.  Examples include the voluntary systems employed by companies like Google to comply with "Right to be Forgotten" policies in the European Union Google-RTBF and the copyright-oriented notice and takedown regime of the United States Digital Millennium Copyright Act (DMCA) Section 512 DMLP-512. </ins> 7. This document benefited from discussions with Stephane Bortzmeyer,


Question: 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.

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


Question: 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.

13.2. <del> In cases where ICE is used to establish some kind of session that is not real time, and has no fixed rate associated with it that is known to work on the network in which ICE is deployed, Ta and RTO revert to more conservative values.  Ta SHOULD be configurable, SHOULD have a default of 500 ms, and MUST NOT be configurable to be less than 500 ms. </del> <ins> ICE agents SHOULD use the default Ta value, 50 ms, but MAY use another value based on the characteristics of the associated media. ICE agents MUST NOT use a Ta value smaller than 5 ms. If an ICE agent wants to use another Ta value than the default value, the agent MUST indicate the proposed value to its peer during the ICE exchange.  Both agents MUST use the higher value of the proposed values.  If an agent does not propose a value, the default value is used for that agent when comparing which value is higher. NOTE: sec-concheckbw shows examples of required bandwidth, using different Ta values. </ins> <del> If other Ta value than the default is used, the agent MUST indicate the value it prefers to use in the ICE exchange.  Both agents MUST use the higher out of the two proposed values. </del> <ins> 13.3. </ins> <del> In addition, the retransmission timer for the STUN transactions, RTO, SHOULD be configurable and during the gathering phase, SHOULD have a default of: </del> <ins> During the ICE gathering phase, ICE agents SHOULD calculate the RTO value using the following formula: </ins> <del> where the number of pairs refers to the number of pairs of candidates with STUN or TURN servers. </del> <ins> For connectivity checks, ICE agents SHOULD calculate the RTO value using the following formula: </ins> <del> For connectivity checks, RTO SHOULD be configurable and SHOULD have a default of: </del> <ins> ICE agents MAY calculate the RTO value using other mechanisms than those described above.  ICE agents MUST NOT use a RTO value smaller than 500 ms. </ins> 14.


Question:
The following issues are addressed in this commit: URL URL
LGTM
To prevent one check list from starving.
This was discussed (and, as far as I am concerned, agreed) on the list 1st June. But, it's good to have a reminder :)
This one has not been addressed as far as I can tell. Now we get to decided if it's important enough or not to do something about :)
I had a look at this, but for some reason it never got implemented. I think it should be an easy fix.
The changes section looks very small compared to how many changes we've made, so it definitely needs updating. Now we need to decide whether we have to update it before or after requesting publication.
Yes - we just have to remember everything :) However, I don't think we should go into details: the major changes (that I can think of when writing this) are removal of regular/aggressive nomination, and the changes related to "Emil's table".
LGTM

In order to limit the attacks described in sec-ice-hammer, an ICE agent MUST limit the total number of connectivity checks the agent <del> performs across all check lists to a specific value, and this value MUST be configurable.  A default of 100 is RECOMMENDED.  This limit is enforced by discarding the lower-priority candidate pairs until there are less than 100.  It is RECOMMENDED that a lower value be utilized when possible, set to the maximum number of plausible checks that might be seen in an actual deployment configuration.  The requirement for configuration is meant to provide a tool for fixing this value in the field if, once deployed, it is found to be problematic. </del> <ins> performs across all check lists in the check list set.  This is done by limiting the total number of candidate pairs in the check list set.  The default limit of candidate pairs for the check list set is 100, but the value MUST be configurable.  The limit is enforced by, within in each check list, discarding lower-priority candidate pairs until the total number of candidate pairs in the check list set is smaller than the limit value.  The discarding SHOULD be done evenly so that the number of candidate pairs in each check list is reduced the same amount. It is RECOMMENDED that a lower limit value than the default is picked when possible, and that the value is set to the maximum number of plausible candidate pairs that might be created in an actual deployment configuration.  The requirement for configuration is meant to provide a tool for fixing this value in the field if, once deployed, it is found to be problematic. </ins> 6.1.2.6.


Question:
The following issues are addressed in this commit: URL URL
LGTM
To prevent one check list from starving.
This was discussed (and, as far as I am concerned, agreed) on the list 1st June. But, it's good to have a reminder :)
This one has not been addressed as far as I can tell. Now we get to decided if it's important enough or not to do something about :)
I had a look at this, but for some reason it never got implemented. I think it should be an easy fix.
The changes section looks very small compared to how many changes we've made, so it definitely needs updating. Now we need to decide whether we have to update it before or after requesting publication.
Yes - we just have to remember everything :) However, I don't think we should go into details: the major changes (that I can think of when writing this) are removal of regular/aggressive nomination, and the changes related to "Emil's table".
LGTM

22. <del> Following is the list of changes from RFC 5245 </del> <ins> The purpose of this updated ICE specification is to: </ins> <del> The specification was generalized to be more usable with any protocol and the parts that are specific to SIP and SDP were moved to a SIP/SDP usage document I-D.ietf-mmusic-ice-sip-sdp. </del> <ins> Clarify procedures in RFC 5245. </ins> <del> Default candidates, multiple components, ICE mismatch detection, subsequent offer/answer, and role conflict resolution were made optional since they are not needed with every protocol using ICE. </del> <ins> Make technical changes, due to discovered flows in RFC 5245 and based on feedback from the community that has implemented and deployed ICE applications based on RFC 5245. </ins> <del> With IPv6, the precedence rules of RFC 6724 are used instead of the obsoleted RFC 3483 and using address preferences provided by the host operating system is recommended. </del> <ins> Make the procedures signaling protocol independent, by removing the SIP and SDP procedures.  Procedures specific to a signaling protocol will be defined in separate usage documents.  I-D.ietf- mmusic-ice-sip-sdp defines the ICE usage with SIP and SDP. </ins> <del> Candidate gathering rules regarding loopback addresses and IPv6 addresses were clarified. </del> <ins> The following technical changes have been done: Aggressive nomination removed. The procedures for calculating candidate pair states and scheduling connectivity checks modified. Procedures for calculation of Ta and RTO modified. Active check list and frozen check list definitions removed. 'ice2' ice option added. IPv6 considerations modified. Usage with no-op for keepalives, and keepalives with non-ICE peers, removed. </ins>


Question:
Made changes to address Warren's first and third, but not 2nd nit. I'm unsure whether the changes in the spacing I introduced will fix the odd spacing in Olle's name.
Warren noted the following nits in his ballot: 1: "Development of The Universal Solution has proved hard, however, for all the usual reasons." -- this is cute, but leaves people wondering what "all the usual reasons are". Perhaps just "Development of The Universal Solution has, however, proved hard." (or just cut after the "however in the original"). 2: I'm not sure why you have "Protocol" in the terminology section. It doesn't seem like it is useful for the document, and this document doesn't seem like the right place to (re) define it. 3: Acknowledgements: Funny spacing in "Olle E. Johansson

identification systems (such as is served by telephone numbers or email addresses in other communications systems). <del> Development of The Universal Solution has proved hard, however, for all the usual reasons. </del> <ins> Development of The Universal Solution has, however, proved hard. </ins> The last few years have also seen a new platform rise for deployment of services: The browser-embedded application, or "Web application".


Question: Spencer had the following comment: I'm not sure how tutorial you want section 4 to be, but I'd at least mention appropriate retransmission and in-order delivery, in addition to congestion control, since you get that with SCTP on the data channel.

entities that handle the data, but do not modify it (such as TURN relays). <del> It includes necessary functions for congestion control: When not to send data. </del> <ins> It includes necessary functions for congestion control, retransmission, and in-order delivery. </ins> WebRTC endpoints MUST implement the transport protocols described in I-D.ietf-rtcweb-transports.


Question:
EKR entered the following DISCUSS: Your citation to ICE is to 5245-bis, but at least the JSEP editor consensus was that WebRTC depended on 5245, so this needs to be resolved one way or the other.
Sean asked me to leave this one open. Personally, I'd somewhat prefer to 5245bis because it separates out the SDP machinery, but JSEP has a specific section reference (section 15.4) that has to go to either 5245 or to mmusic-ice-sip-sdp, and one could argue that we need to pull in -sip-sdp here too. I'm OK with 5245 as a reference, but will let the chairs make the call.
I no longer care about this distinction.

multiple data channels between them. An implementation of the Interactive Connectivity Establishment <del> (ICE) I-D.ietf-ice-rfc5245bis protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). </del> <ins> (ICE) RFC5245 protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). </ins> Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another


Question:
reformulated the TCP point, addressed security with a reference to -qos.
From Ben Campbell's review:
Second point is fixed by . I'm not sure the third point is an improvement.
SSL is used exactly once, as part of the acronym "TURN/SSL". This is also the first mention of TURN, but the second was much more convenient to attach the expansion to. Given that it was so awkward to attach them, I included a new section listing the "used protocols" instead.
From Magnus Westerlund in IETF LC: Section 8.1: [I-D.martinsen-mmusic-ice-dualstack-fairness] Martinsen, P., Reddy, T., and P. Patil, "ICE IPv4/IPv6 Dual Stack Fairness", draft-martinsen-mmusic-ice- dualstack-fairness-02 (work in progress), February 2015. Can be updated as this is now an WG item in ICE.
Updated in
Fixed by
I have reviewed this document in preparation for IETF last call. It is in good shape and I have requested the last call. While the last call is ongoing, I would like to double-check that this document (particularly Section 4) raises no new security considerations that should be documented in Section 6. I'm wondering if there are scenarios where a malicious application could try to game the priority scheme to some ill effect? draft-ietf-tsvwg-rtcweb-qos talks a bit about this, so I'm wondering if anything needs to be said here. And I found a couple of nits to be resolved together with any LC comments: Sec 3.2 - Please update the citation to point to draft-ietf-mmusic-ice-dualstack-fairness-02. Sec 3.4 - "Third, using TCP only between the endpoint and its relay may result in less issues with TCP in regards to real-time constraints, e.g. due to head of line blocking." This is awkwardly phrased. I would suggest something like "Third, using TCP between the client's TURN server and its peer may result in more performance problems (due to head-of-line blocking) than using UDP." And one bit I left out — if text is to be added to reference draft-ietf-rtcweb-return, that should be done together with addressing nits and LC comments.
There seems no consensus to add RETURN, so I'm skipping this for now.

browser MUST be able to communicate. When TURN is used, and the TURN server has IPv4 or IPv6 connectivity <del> to the peer or its TURN server, candidates of the appropriate types MUST be supported.  The "Happy Eyeballs" specification for ICE I- D.martinsen-mmusic-ice-dualstack-fairness SHOULD be supported. </del> <ins> to the peer or the peer's TURN server, candidates of the appropriate types MUST be supported.  The "Happy Eyeballs" specification for ICE I-D.ietf-mmusic-ice-dualstack-fairness SHOULD be supported. </ins> 3.3.


Question:
reformulated the TCP point, addressed security with a reference to -qos.
From Ben Campbell's review:
Second point is fixed by . I'm not sure the third point is an improvement.
SSL is used exactly once, as part of the acronym "TURN/SSL". This is also the first mention of TURN, but the second was much more convenient to attach the expansion to. Given that it was so awkward to attach them, I included a new section listing the "used protocols" instead.
From Magnus Westerlund in IETF LC: Section 8.1: [I-D.martinsen-mmusic-ice-dualstack-fairness] Martinsen, P., Reddy, T., and P. Patil, "ICE IPv4/IPv6 Dual Stack Fairness", draft-martinsen-mmusic-ice- dualstack-fairness-02 (work in progress), February 2015. Can be updated as this is now an WG item in ICE.
Updated in
Fixed by
I have reviewed this document in preparation for IETF last call. It is in good shape and I have requested the last call. While the last call is ongoing, I would like to double-check that this document (particularly Section 4) raises no new security considerations that should be documented in Section 6. I'm wondering if there are scenarios where a malicious application could try to game the priority scheme to some ill effect? draft-ietf-tsvwg-rtcweb-qos talks a bit about this, so I'm wondering if anything needs to be said here. And I found a couple of nits to be resolved together with any LC comments: Sec 3.2 - Please update the citation to point to draft-ietf-mmusic-ice-dualstack-fairness-02. Sec 3.4 - "Third, using TCP only between the endpoint and its relay may result in less issues with TCP in regards to real-time constraints, e.g. due to head of line blocking." This is awkwardly phrased. I would suggest something like "Third, using TCP between the client's TURN server and its peer may result in more performance problems (due to head-of-line blocking) than using UDP." And one bit I left out — if text is to be added to reference draft-ietf-rtcweb-return, that should be done together with addressing nits and LC comments.
There seems no consensus to add RETURN, so I'm skipping this for now.

establishing UDP relay candidates using TURN over TCP to connect to their respective relay servers. <del> Third, using TCP only between the endpoint and its relay may result in less issues with TCP in regards to real-time constraints, e.g. due to head of line blocking. </del> <ins> Third, using TCP between the client's TURN server and the peer may result in more performance problems than using UDP, e.g. due to head of line blocking. </ins> ICE-TCP candidates RFC6544 MUST be supported; this may allow applications to communicate to peers with public IP addresses across


Question:
reformulated the TCP point, addressed security with a reference to -qos.
From Ben Campbell's review:
Second point is fixed by . I'm not sure the third point is an improvement.
SSL is used exactly once, as part of the acronym "TURN/SSL". This is also the first mention of TURN, but the second was much more convenient to attach the expansion to. Given that it was so awkward to attach them, I included a new section listing the "used protocols" instead.
From Magnus Westerlund in IETF LC: Section 8.1: [I-D.martinsen-mmusic-ice-dualstack-fairness] Martinsen, P., Reddy, T., and P. Patil, "ICE IPv4/IPv6 Dual Stack Fairness", draft-martinsen-mmusic-ice- dualstack-fairness-02 (work in progress), February 2015. Can be updated as this is now an WG item in ICE.
Updated in
Fixed by
I have reviewed this document in preparation for IETF last call. It is in good shape and I have requested the last call. While the last call is ongoing, I would like to double-check that this document (particularly Section 4) raises no new security considerations that should be documented in Section 6. I'm wondering if there are scenarios where a malicious application could try to game the priority scheme to some ill effect? draft-ietf-tsvwg-rtcweb-qos talks a bit about this, so I'm wondering if anything needs to be said here. And I found a couple of nits to be resolved together with any LC comments: Sec 3.2 - Please update the citation to point to draft-ietf-mmusic-ice-dualstack-fairness-02. Sec 3.4 - "Third, using TCP only between the endpoint and its relay may result in less issues with TCP in regards to real-time constraints, e.g. due to head of line blocking." This is awkwardly phrased. I would suggest something like "Third, using TCP between the client's TURN server and its peer may result in more performance problems (due to head-of-line blocking) than using UDP." And one bit I left out — if text is to be added to reference draft-ietf-rtcweb-return, that should be done together with addressing nits and LC comments.
There seems no consensus to add RETURN, so I'm skipping this for now.

6. <del> Security considerations are enumerated in I-D.ietf-rtcweb-security. </del> <ins> RTCWEB security considerations are enumerated in I-D.ietf-rtcweb- security. Security considerations pertaining to the use of DSCP are enumerated in I-D.ietf-tsvwg-rtcweb-qos. </ins>


Question:
NAME please review
From Magnus Westerlund in IETF LC review: Section 3.4: If TCP connections are used, RTP framing according to [RFC4571] MUST be used, both for the RTP packets and for the DTLS packets used to carry data channels. I think the last part of this sentence, unintentionally excludes the DTLS handshake packets. The ICE TCP spec also specifies that the STUN connectivity checks are using RFC4571 framing. Thus, I think some reformulation of this sentence is in order.

UDP-blocking firewalls without using a TURN server. If TCP connections are used, RTP framing according to RFC4571 MUST be <del> used, both for the RTP packets and for the DTLS packets used to carry data channels. </del> <ins> used for all packets.  This includes the RTP packets, DTLS packets used to carry data channels, and STUN connectivity check packets. </ins> The ALTERNATE-SERVER mechanism specified in RFC5389 (STUN) section 11 (300 Try Alternate) MUST be supported.


Question: Just saving some typing because this section will eventually need to match what's in RFC8174.

2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </del> <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. </ins> 3.


Question:
NAME PTAL
The current text on user identity covers the domain portion well enough, but doesn't really say anything about how the part preceding the 'NAME is handled. There is text regarding the use of a local address book for the purposes of rendering, which might help avoid these issues entirely... where available. We may need to consider addressing the issue of confusable characters and whether we need to define the use of a particular normalization form. (See )

authoritative IdPs, thus allowing the user to instantly grasp that the call is being authenticated by Facebook, Google, etc. <ins> 6.4.4.1. Because a broad range of characters are permitted in identity strings, it may be possible for attackers to craft identities which are confusable with other identities (see RFC6943 for more on this topic).  This is a problem with any identifier space of this type (e.g., e-mail addresses).  Those minting identifers should avoid mixed scripts and similar confusable characters.  Those presenting these identifiers to a user should consider highlighting cases of mixed script usage (see RFC5890, section 4.4).  Other best practices are still in development. </ins> 6.4.5. A number of optional Web security features have the potential to


Question:
See email from paul L Nov1 to media-types Hello Cullen, it seems to me that all the content-types you have been describing about senML are candidate content types to be exchanged over the clipboard of a normal mobile or desk computer; e.g. from a reading app to another, … Do you agree on this? If yes, then I’d like to recommend to add: MacOS Uniform Type Identiers Windows Clipboard Name for each of the content-types. If there is earlier experience in this realm, probably this should be taken, otherwise, I can probably suggest some clipboard names. Standardising such at the Media-Type declaration level allows to set a reference frame so that other implementations can follow, just as the content-type name. For examples of including this in the media-type registration, see that of SVG or MathML. thanks in advance. Paul
At IETF 97 was "probably should do this" - see URL
See MathML at URL
On the UTI, currently only apple can declare ones in the public space ( see URL ). I do not see how to request one. There is a bunch of extra info apple would need to add to the OS to really make this work outlined in URL
Windows clipboard info at URL(v=vs.85).aspx
Makes sense; no need for a clipboard format for the streaming and compressed versions actually.

11.3. The following registrations are done following the procedure <del> specified in RFC6838 and RFC7303. </del> <ins> specified in RFC6838 and RFC7303.  Clipboard formats are defined for the JSON and XML form of lists but do not make sense for streams or other formats. </ins> Note to RFC Editor - please remove this paragraph.  Note that a request for media type review for senml+json was sent to the media-


Question:
See email from paul L Nov1 to media-types Hello Cullen, it seems to me that all the content-types you have been describing about senML are candidate content types to be exchanged over the clipboard of a normal mobile or desk computer; e.g. from a reading app to another, … Do you agree on this? If yes, then I’d like to recommend to add: MacOS Uniform Type Identiers Windows Clipboard Name for each of the content-types. If there is earlier experience in this realm, probably this should be taken, otherwise, I can probably suggest some clipboard names. Standardising such at the Media-Type declaration level allows to set a reference frame so that other implementations can follow, just as the content-type name. For examples of including this in the media-type registration, see that of SVG or MathML. thanks in advance. Paul
At IETF 97 was "probably should do this" - see URL
See MathML at URL
On the UTI, currently only apple can declare ones in the public space ( see URL ). I do not see how to request one. There is a bunch of extra info apple would need to add to the OS to really make this work outlined in URL
Windows clipboard info at URL(v=vs.85).aspx
Makes sense; no need for a clipboard format for the streaming and compressed versions actually.

File extension(s): senml and sensml <ins> Windows Clipboard Name: "JSON Sensor Measurement List" for senml </ins> Macintosh file type code(s): none <ins> Macintosh Universal Type Identifier code: org.ietf.senml-json conforms to public.text for senml </ins> Person & email address to contact for further information: Cullen Jennings <fluffy@iii.ca>


Question:
See email from paul L Nov1 to media-types Hello Cullen, it seems to me that all the content-types you have been describing about senML are candidate content types to be exchanged over the clipboard of a normal mobile or desk computer; e.g. from a reading app to another, … Do you agree on this? If yes, then I’d like to recommend to add: MacOS Uniform Type Identiers Windows Clipboard Name for each of the content-types. If there is earlier experience in this realm, probably this should be taken, otherwise, I can probably suggest some clipboard names. Standardising such at the Media-Type declaration level allows to set a reference frame so that other implementations can follow, just as the content-type name. For examples of including this in the media-type registration, see that of SVG or MathML. thanks in advance. Paul
At IETF 97 was "probably should do this" - see URL
See MathML at URL
On the UTI, currently only apple can declare ones in the public space ( see URL ). I do not see how to request one. There is a bunch of extra info apple would need to add to the OS to really make this work outlined in URL
Windows clipboard info at URL(v=vs.85).aspx
Makes sense; no need for a clipboard format for the streaming and compressed versions actually.

File extension(s): senmlx and sensmlx <ins> Windows Clipboard Name: "XML Sensor Measurement List" for senmlx </ins> Macintosh file type code(s): none <ins> Macintosh Universal Type Identifier code: org.ietf.senml-xml conforms to publc.xml for senmlx </ins> Person & email address to contact for further information: Cullen Jennings <fluffy@iii.ca>


Question:
This should now consider and . There are no perfect solutions for these, but the solutions chosen should be close.
I don't agree wth some of this but agree with a bunch. I took carsten's changes for all the parts I agree with and put them in URL
I might suggest we pull that PR and then look at what is left (on a bunch of them it is simply if there should be an * suggesting don't use or not) then we can rebase this PR and see what is left to resolve.
Oops, I just changed my PR to react to your comments before seeing
Pushed another version that has both / and % for the same thing, where % is marked with a *
Now, instead of delete, it's "not recommend" and mentions kg as exception. I think this is good to merge.
The following units are questionable: % -- this looks like a percentage (0..100), but it is not (0..1). count -- what? This is about a dimensionless quantity? %RH, %EL appear to be percentages, but imply a quantity. EL may be a quantity, but the unit is second. In SI, we don't do new units for new quantities (there is no "millimeter radius" or "nanometer wavelength"). Bspl -- this really should be in dB (see ), SPL is the quantity again. beat/min, beats -- these should be 1/min (but see ) and 1 (dimensionless); how is beats different from count? We don't have bit (but bit/s), byte. 1/min is there only for heartbeats, not for revolutions ("rpm"). Should really be 1/s (but see ). lat and lon are a bit weird, too. (Celsius is also questionable -- the rationale of should call for all measurements being expressed in Kelvin.)
on on kevin vs C, every thermostat manufacture I can find has said they want C over kelvin. bunch of implementation are using 0 to 1 for light levels but imagine we could change % to 0 to 100 count - yep count :-) Bunch of sensors simply count pulses of who knows what. Totally agree this is not a unit but this is the pragmatic sort of thing needed EL is a great example of something that many sensors in sports have to deal with in common way. They use this and it works well for them
So I changed % to mean percentage. Cel of course stays in (even though it is wrong wrong wrong :-). I have marked count and EL with the "not so recommended for new producers" range. But we don't really have a base unit for "1" (dimensionless) either. The problem remains that giving a unit doesn't tell you what quantity actually has been measured, and the trend to make more and more finer grained units for the same kinds quantities measured in different ways (as in psi vs. psig etc.) leads into the woods.
just finding all the email now … I think the thing that people like about this is it’s not a SI unit, it’s something that tells you something useful about what you are measuring across a wide range of devices. I think we need to think of these from a point of view of broadly useful than are they a SI unit. Agree with your slippery slope psi, psig, etc argument but all of those exist for a reason.
The SI unit for mass is kg. says: That leads to being unable to use the SI unit for mass, instead, we are using g. But then we are using derived units such as l (dm3) and l/s (dm3/s). So: We need to decide the above TODO. We need to decide whether to stick with SI units or allow simple names for derived units (gram, minute, liter). Domain-specific units are often weird (1/min = "rpm", mmHg or mol/dl in medicine, ...).
I think a key part of the registry vs existing SI unit tables was to be able to use things that were not proper units but agree things can be cleaned up. Clearly rpm and bpm have the same unit in the sense of what the dimensions are but what they are used to measure are pretty different and knowing that it is bpm often provides a level of information about how to process the information. As related to our whole conversation on why we needed the IANA table, the ability to have things in this that are not really a classic SI unit is the key value of SenML. The rules are just guidelines. If we want to change the unit of mass from g to kg, we can do that but the point on the prefixes was not to have both g and kg as that just reduces interoperability

IANA will create a registry of SenML unit symbols.  The primary purpose of this registry is to make sure that symbols uniquely map to give type of measurement.  Definitions for many of these units can be <del> found in location such as NIST811 and BIPM. </del> <ins> found in location such as NIST811 and BIPM.  Units marked with an asterisk are NOT RECOMMENDED to be produced by new implementations, but are in active use and SHOULD be implemented by consumers that can use the related base units. </ins> Note 1: A value of 0.0 indicates the switch is off while 1.0 <del> indicates on and 0.5 would be half on. </del> <ins> indicates on and 0.5 would be half on.  The preferred name of this unit is "/".  For historical reasons, the name "%" is also provided for the same unit - but note that while that name strongly suggests a percentage (0..100) -- it is however NOT a percentage, but the absolute ratio! </ins> Note 2: Assumed to be in WGS84 unless another reference frame is known for the sensor.


Question:
This should now consider and . There are no perfect solutions for these, but the solutions chosen should be close.
I don't agree wth some of this but agree with a bunch. I took carsten's changes for all the parts I agree with and put them in URL
I might suggest we pull that PR and then look at what is left (on a bunch of them it is simply if there should be an * suggesting don't use or not) then we can rebase this PR and see what is left to resolve.
Oops, I just changed my PR to react to your comments before seeing
Pushed another version that has both / and % for the same thing, where % is marked with a *
Now, instead of delete, it's "not recommend" and mentions kg as exception. I think this is good to merge.
The following units are questionable: % -- this looks like a percentage (0..100), but it is not (0..1). count -- what? This is about a dimensionless quantity? %RH, %EL appear to be percentages, but imply a quantity. EL may be a quantity, but the unit is second. In SI, we don't do new units for new quantities (there is no "millimeter radius" or "nanometer wavelength"). Bspl -- this really should be in dB (see ), SPL is the quantity again. beat/min, beats -- these should be 1/min (but see ) and 1 (dimensionless); how is beats different from count? We don't have bit (but bit/s), byte. 1/min is there only for heartbeats, not for revolutions ("rpm"). Should really be 1/s (but see ). lat and lon are a bit weird, too. (Celsius is also questionable -- the rationale of should call for all measurements being expressed in Kelvin.)
on on kevin vs C, every thermostat manufacture I can find has said they want C over kelvin. bunch of implementation are using 0 to 1 for light levels but imagine we could change % to 0 to 100 count - yep count :-) Bunch of sensors simply count pulses of who knows what. Totally agree this is not a unit but this is the pragmatic sort of thing needed EL is a great example of something that many sensors in sports have to deal with in common way. They use this and it works well for them
So I changed % to mean percentage. Cel of course stays in (even though it is wrong wrong wrong :-). I have marked count and EL with the "not so recommended for new producers" range. But we don't really have a base unit for "1" (dimensionless) either. The problem remains that giving a unit doesn't tell you what quantity actually has been measured, and the trend to make more and more finer grained units for the same kinds quantities measured in different ways (as in psi vs. psig etc.) leads into the woods.
just finding all the email now … I think the thing that people like about this is it’s not a SI unit, it’s something that tells you something useful about what you are measuring across a wide range of devices. I think we need to think of these from a point of view of broadly useful than are they a SI unit. Agree with your slippery slope psi, psig, etc argument but all of those exist for a reason.
The SI unit for mass is kg. says: That leads to being unable to use the SI unit for mass, instead, we are using g. But then we are using derived units such as l (dm3) and l/s (dm3/s). So: We need to decide the above TODO. We need to decide whether to stick with SI units or allow simple names for derived units (gram, minute, liter). Domain-specific units are often weird (1/min = "rpm", mmHg or mol/dl in medicine, ...).
I think a key part of the registry vs existing SI unit tables was to be able to use things that were not proper units but agree things can be cleaned up. Clearly rpm and bpm have the same unit in the sense of what the dimensions are but what they are used to measure are pretty different and knowing that it is bpm often provides a level of information about how to process the information. As related to our whole conversation on why we needed the IANA table, the ability to have things in this that are not really a classic SI unit is the key value of SenML. The rules are just guidelines. If we want to change the unit of mass from g to kg, we can do that but the point on the prefixes was not to have both g and kg as that just reduces interoperability

single canonical representation outweighs the convenience of easy human representations or loss of precision in a conversion. <del> Use of SI prefixes such as "k" before the unit is not allowed. </del> <ins> Use of SI prefixes such as "k" before the unit is not recommended. </ins> Instead one can represent the value using scientific notation such <del> a 1.2e3.  TODO - Open Issue.  Some people would like to have SI prefixes to improve human readability. </del> <ins> a 1.2e3.  The "kg" unit is exception to this rule since it is an SI base unit; the "g" unit is provided for legacy compatibility. </ins> For a given type of measurement, there will only be one unit type defined.  So for length, meters are defined and other lengths such


Question:
I think that the hash/auth tag list should be better moved at the end of the frame after the auth tag to make it easier to apply the encryption and generating the auth tag without having to reconstruct the frame to insert the signature in the middle of it. So, my new proposal would be first to generate the frame header with the s bit = 1, append the payload, encrypt the frame and add the auth tag as normal: Then append the tags before that frame at the end and the number of auth tags without the current frame one Then calculate the signature of the auth tags in reverse order: And then append the Signature at the end of the frame: When the receiver gets the frame, it will also be able to reuse the buffer to calculate the Signature without having to move momory around. In case it is not secure to use the auth tags, it would be still be similar: The receiver would have to generate the Hash of the frame up to the Auth tag, and then calculate the signature with the rest of the hashes on the list.
Adding Signature at the end will mean adding a new offset field to point to where the Signature block start as it will be a variable length block (depends how many hashes it has), where if it was put at the beginning, we won't need to add an offset field.I think doing signature over the auth tag is fineYou are right about the startFrameIndex, it won't be enough. What about having startFrameIndex 4 bytes or whatever, then having one byte frameOffset for every other hash to get the frameindex by using this offset from the start index, assuming 255 is enough range. I just don't want to add full length frameId for every hash
didn't you said that: Why is it fixed if it is at the beginning, but variable if it is in the end? why do we need the at all? The receiver would just need to have an ordered map of the pending to be verified authentication tags and remove them when they signature for each is received. The receiver should have also a verification timeout and if a signature is not received for that tag in time, it would be considered as failed.
Ok, I see, ECDSA signatures are ASN1 encoded objects, so the length can be derived by parsing it from the start bite. Is that correct?
I have made a new tentative approach with my comments above. What do you think?
Sorry I should have been more clear The signature itself is fixed length (ex 64 bytes for ed25519) but The entire signature block will be variable depends on the number of signature, unless you want to make this number fixed (ex always 50 hashes)We need frameIndex so the recipient know which hashes to use to verify the signature, we can't just relay on an ordered list of all previous hashes because the signature block could have hashes of missing frames, or even the signature packet could be lost itself
What is a signature block? What is the difference between the signature and the signature block? That should be covered by my proposal.
signature = sign(data) Signature block is what I referred to on my drawing as signature header+ signature + hash list
If I understood your proposal correctly, you are sending the whole list of hashes so the receiver can recreate the if any of them is missing. So you don't really don't need the index of each frame, as you there should be (almost) a 1-to-1 mapping between the hashes/auth tag and the frame index (how probable is to have a hash or auth tag collision?). So, given the hash/auth tag list, the receiver could derive the frame index of it (by keeping an internal map)
I think that's good for now. My initial thought was to have the sender chose the packet to sign, they can be different number each time, also they might chose not ti sign every packet, for example random X packets every Y seconds. Anyway, we can always improve later, your proposal is good to start with
This should be also possible with current approach, right? Have you seen any reason that it couldn't be done?
In the draft it says that: >when the signature is sent, it will also send all the hashes it used to calculate the signature How is the bitstream format of the signature+hashes, also how is the signature added to the frame (after the auth tag?) and how is the presence of the signature in a frame signaled?
How about something like this for the signature format? The signature is appended after the block if the bit of the SFrame header is 1. The first byte (SLEN) is the length of the signature data . After the signature there will be 1 or more blocks of HMACs. A they can be off different size, each HMAC block will have 1 byte header with HNUM (4 bits) indicating the number of HMACs present and HLEN(4 bits) to indicate the size in bytes of each HMAC. To indicate the end of the HMACS blocks an HMAC header block with HNUM=0 and HLEN=0 will be inserted.
One question, what are the sizes of the HMACs? I have considered the ones for AES which are 4 and 8, but in GCM are bigger, right? Are they required to be even or a power of 2? we could do either length=2^(HLEN+1) or LEN=2(HLEN+2) in that case.
I don't think they have to be 2*n. SHA-256 is, of course, but SHA-384 isn't
Currently it says that: However, if using SVC, the hash will be calculated over all the frames of the different spatial layers within the same superframe/picture. However the SFU will be able to drop frames within the same stream (either spatial or temporal) to match target bitrate. In that case, the receiver will never get a full frame and be able to check the signature. Which will render it a kind of useless feature. An easy way of solving the issue would be to perform signature only on the base layer or take into consideration the dependency graph and send multiple signatures in parallel (each for a branch of the dependency graph).
This is a good point and suggests 'frame' really refers to each independently decodable unit.
I think I mixed two things on this issue and my original comment is not totally accurate. The signature will contain the HMAC of all the frames it contains, so if any of them is dropped, the receiver can still compute the signature of the received ones. However, if the signature is not sent on the base layer, then it can be dropped by the SFU. I think it still makes sense to send different signatures over different layers to avoid having to send data on the wire that will be dropped by the SFU.

extra cost. Adding a digital signature to each encrypted frame will be an <del> overkill, instead we propose adding signature over N frames. Because some frames could be lost and never delivered, when the signature is sent, it will also send all the hashes it used to calculate the signature, and the recipient client will only use these hashes if they didn't receive the matching frame.  For example Client A sends a signature every 5 frames, so it sends the signature and Hash(Frame1), ...,Hash(Frame5), client B received only frames 1,2,4 and 5.  When B receives the signature and the hashes, it will compute the hashes of frames 1,2,4 and 5 locally and use the received Hash(Frame3) to verify the signature.  It is up to the application to decide what to do when signature verification fails. The signature keys are exchanged out of band along the secret keys. </del> <ins> overkill, instead we propose adding signature over multiple frames. The signature is calculated by contatenating the authentication tags of the frames that the sender wants to authenticate (in reverse sent order) and signing it with the signature key.  Signature keys are exchanged out of band along the secret keys. The authentication tags for the previous frames covered by the signature and the signature itself will be appended at end of the frame, after the current frame authentication tag, in the same order that the signature was calculated, and the SFrame header metadata signature bit (S) will be set to 1. Note that the authentication tag for the current frame will only authenticate the SFrame header and the encrypted payload, ant not the signature nor the previous frames's authentication tags (N-1 to N-M) used to calculate the signature. The last byte (NUM) after the authentication tag list and before the signature indicates the number of the authentication tags from previous frames present in the current frame.  All the authentications tags MUST have the same size, which MUST be equal to the authentication tag size of the current frame.  The signature is fixed size depending on the signature algorithm used (for example, 64 bytes for Ed25519). The receiver has to keep track of all the frames received but yet not verified, by storing the authentication tags of each received frame. When a signature is received, the reciever will verify it with the signature key associated to the key id of the frame the singature was sent in.  If the verification is sucessful, the received will mark the frames as authenticated and remove them from the list of the not verified frames.  It is up to the application to decide what to do when signature verification fails. When using SVC, the hash will be calculated over all the frames of the different spatial layers within the same superframe/picture. However the SFU will be able to drop frames within the same stream (either spatial or temporal) to match target bitrate. If the signature is sent on a frame which layer that is dropped by the SFU, the receiver will not receive it and will not be able to perform the signature of the other received layers. An easy way of solving the issue would be to perform signature only on the base layer or take into consideration the frame dependency graph and send multiple signatures in parallel (each for a branch of the dependency graph). In case of simulcast or K-SVC, each spatial layer sould be authenticated with different signatures to prevent the SFU to discard frames with the signature info. In any case, it is possible that the frame with the signature is lost or the SFU drops it, so the receiver MUST be prepared to not receive a signature for a frame and remove it from the pending to be verified list after a timeout. </ins> 4.


Question:
This adds a security consideration for padding. THis addresses issue
With the move from CBC to GCM as a padding mode, there is now no padding for a S/MIME message at all. We should probably add a security consideration dealing with the fact that in some cases traffic analysis might be able to get at the content of an encrypted message based on its size.

Modification of the ciphertext can go undetected if authentication is not also used, which is the case when sending EnvelopedData without <del> wrapping it in SignedData or enclosing SignedData within it. </del> <ins> wrapping it in SignedData or enclosing SignedData within it.  This is one of the reasons for moving from EnvelopedData to AuthEnvelopedData as the authenticated encryption algorithms provide the authentication without needing the SignedData layer. </ins> If an implementation is concerned about compliance with National Institute of Standards and Technology (NIST) key size


Question:
This adds a security consideration for padding. THis addresses issue
With the move from CBC to GCM as a padding mode, there is now no padding for a S/MIME message at all. We should probably add a security consideration dealing with the fact that in some cases traffic analysis might be able to get at the content of an encrypted message based on its size.

the fact that the CEK is going to be known to both parties.  Thus the origination is always built on a presumption that "I did not send this message to myself." <ins> All of the authenticated encryption algorithms in this document use counter mode for the encryption portion of the algorithm.  This means that the length of the plain text will always be known as the cipher text length and the plain text length are always the same.  This information can enable passive observers to infer information based solely on the length of the message.  Applications for which this is a significant problem need to provide some type of padding algorithm so that the length of the message does not provide this information. </ins>


Question: …fix the various typos flagged by DKG, submit as WG draft.

4- The multiplexed server establishes the connection to the protected service, thus revealing the identity of the service. <ins> One of the goals of SNI encryption is to prevent adversaries from knowing which Hidden Service the client is using.  Successful replay attacks breaks that goal by allowing adversaries to discover that service. </ins> SNI encryption designs MUST mitigate this attack. 2.2.


Question: …fix the various typos flagged by DKG, submit as WG draft.

HTTPS, which effectively treats the Fronting Server as an HTTP Proxy. In this solution, the client establishes a TLS connection to the Fronting Server, and then issues an HTTP Connect request to the <del> Hidden Server.  This will effectively establish an end-to-end HTTPS over TLS connection between the client and the Hidden Server, mitigating the issues described in nocontextsharing. </del> <ins> Hidden Server.  This will establish an end-to-end HTTPS over TLS connection between the client and the Hidden Server, mitigating the issues described in nocontextsharing. </ins> The HTTPS in HTTPS solution requires double encryption of every packet.  It also requires that the fronting server decrypts and relay


Question: …fix the various typos flagged by DKG, submit as WG draft.

Antoine Delignaut-Lavaud. The delegation token design comes from many people, including Ben <del> Schwartz and Rich Salz. </del> <ins> Schwartz, Brian Sniffen and Rich Salz. </ins> 9.  References


Question: the automated key management reference was made in error. RFC4107 is about systems like IKEv2, TLS, etc. where a key has to be agreed upon between two (or more nodes). The key needed for the encrypted state token never leaves the sender, so it can be a randomly generated key, provided that the nonce is never repeated. This text fixed the considerations for this section.

Transporting the state needed by a client to process a response as serialized state information in the token has several significant and non-obvious security and privacy implications that need to be <del> mitigated; see serialized-state for recommendations.  In addition to the format requirements outlined there, implementations need to ensure that they are not vulnerable to maliciously crafted, delayed, or replayed tokens. </del> <ins> mitigated; see serialized-state for recommendations. In addition to the format requirements outlined there, implementations need to ensure that they are not vulnerable to maliciously crafted, delayed, or replayed tokens. </ins> It is generally expected that the use of encryption, integrity protection, and replay protection for serialized state is <del> appropriate.  In the absence of integrity and reply protection, an on-path attacker or rogue server/intermediary could return a state (either one modified in a reply, or an unsolicited one) that could alter the internal state of the client.  It is this reason that at least the use of integrity protection on the token is always recommended. </del> <ins> appropriate. In the absence of integrity and reply protection, an on-path attacker or rogue server/intermediary could return a state (either one modified in a reply, or an unsolicited one) that could alter the internal state of the client. It is this reason that at least the use of integrity protection on the token is always recommended. </ins> It maybe that in some very specific case, as a result of a careful and detailed analysis of any potential attacks, that there may be cases where such cryptographic protections do not add value.  The <del> authors of this document have not found such a use case as yet. RFC3610 with a 64-bit tag is RECOMMENDED, combined with a sequence number and a replay window.  Where encryption is not needed, RFC6234, combined with a sequence number and a replay window, may be used. </del> <ins> authors of this document have not found such a use case as yet, but this is a local decision. It should further be emphasized that the encrypted state is created by the sending node, and decrypted by the same node when receiving a response.  The key is not shared with any other system.  Therefore the choice of encryption scheme and the generation of the key for this system is purely a local matter. When encryption is used, the use of RFC3610 with a 64-bit tag is recommended, combined with a sequence number and a replay window. This choice is informed by available hardware acceleration of on many constrained systems.  If a different algorithm is available accelerated on the sender, with similar strength, then it SHOULD be preferred.  Where privacy of the state is not required, and encryption is not needed, RFC6234, combined with a sequence number and a replay window, may be used. This size of the replay window depends upon the number of outstanding requests that need to be outstanding.  This can be determined from the rate at which new ones are made, and the expected duration in which responses are expected. For instance, given a CoAP ACK_TIMEOUT of 2s, and a request rate of 10 requests/second, any request that is not answered within 2s will be considered to have failed.  Thus at most 20 request can be outstanding at a time, and any convenient replay window larger than 20 will work.  As replay windows are often implemented with a sliding window and a bit, the use of a 32-bit window would be sufficient. For use cases where requests are being relayed from another node, the request rate may be estimated by the total link capacity allocated for that kind of traffic.  An alternate view would consider how many IPv6 Neighbor Cache Entries (NCEs) the system can afford to allocate for this use. </ins> When using an encryption mode that depends on a nonce, such as AES- CCM, repeated use of the same nonce under the same key causes the <del> cipher to fail catastrophically.  If a nonce is ever used for more than one encryption operation with the same key, then the same key stream gets used to encrypt both plaintexts and the confidentiality guarantees are voided.  Devices with low-quality entropy sources -- as is typical with constrained devices, which incidentally happen to be a natural candidate for the stateless mechanism described in this document -- need to carefully pick a nonce generation mechanism that provides the above uniqueness guarantee.  Additionally, since it can be difficult to use AES-CCM securely when using statically configured keys, implementations should use RFC4107. </del> <ins> cipher to fail catastrophically. If a nonce is ever used for more than one encryption operation with the same key, then the same key stream gets used to encrypt both plaintexts and the confidentiality guarantees are voided.  Devices with low-quality entropy sources -- as is typical with constrained devices, which incidentally happen to be a natural candidate for the stateless mechanism described in this document -- need to carefully pick a nonce generation mechanism that provides the above uniqueness guarantee. RFC8613 appendix B.1.1 ("Sender Sequence Number") provides a model for how to maintain non-repeating nonces without causing excessive wear of flash. </ins> 6.


Question:
Thanks for your comment, Russ. Here is the issue: Only after the swap has been completed the plaintext firmware image is in the primary slot. Before the swap, the encrypted firmware image was in the secondary slot. It would be possible to do a "dummy decrypt" to compute the hash prior to doing the decrypt with swapping.
Yes, the AES-CTR and AES-CBC document in the COSE WG states that the signature provides the integrity protection, so this description needs to say how that happens.
Russ, I have added text to address your comment.

8. <del> The ability to restart an interrupted firmware update is often a requirement for low-end IoT devices.  To fulfill this requirement it is necessary to chunk a larger firmware image into blocks and to encrypt each block individually using a cipher that does not increase the size of the resulting ciphertext (i.e., by not adding an authentication tag after each encrypted block). </del> <ins> Flash memory on microcontrollers is a type of non-volatile memory that erases data in units called blocks, pages or sectors and re- writes data at byte level (often 4-bytes).  Flash memory is furthermore segmented into different memory regions, which store the bootloader, different versions of firmware images (in so-called slots), and configuration data. image-layout shows an example layout of a microcontroller flash area.  The primary slot contains the firmware image to be executed by the bootloader, which is a common deployment on devices that do not offer the concept of position independent code. </ins> When the encrypted firmware image has been transferred to the device, <del> it will typically be stored in a staging area.  Then, the bootloader starts decrypting the downloaded image block-by-block and swaps it with the currently valid image.  Note that the currently valid image is available in cleartext and hence it has to be re-encrypted before copying it to the staging area. </del> <ins> it will typically be stored in a staging area, in the secondary slot in our example. At the next boot, the bootloader will recognize a new firmware image in the secondary slot and will start decrypting the downloaded image sector-by-sector and will swap it with the image found in the primary slot. The swap should only take place after the signature on the plaintext is verified.  Note that the plaintext firmware image is available in the primary slot only after the swap has been completed, unless "dummy decrypt" is used to compute the hash over the plaintext prior to executing the decrypt operation during a swap.  Dummy decryption here refers to the decryption of the firmware image found in the secondary slot sector-by-sector and computing a rolling hash over the resulting plaintext firmware image (also sector-by-sector) without performing the swap operation.  While there are performance optimizations possible, such as conveying hashes for each sector in the manifest rather than a hash of the entire firmware image, such optimizations are not described in this specification. </ins> This approach of swapping the newly downloaded image with the previously valid image is often referred as A/B approach.  A/B refers <del> to the two storage areas, sometimes called slots, involved.  Two slots are used to allow the update to be reversed in case the newly obtained firmware image fails to boot.  This approach adds robustness to the firmware update procedure. </del> <ins> to the two slots involved.  Two slots are used to allow the update to be reversed in case the newly obtained firmware image fails to boot. This approach adds robustness to the firmware update procedure. Since the image in primary slot is available in cleartext it may need to re-encrypted it before copying it to the secondary slot.  This may be necessary when the secondary slot has different access permissions or when the staging area is located in an off-chip flash memory and therefore more vulnerable to physical attacks.  Note that this description assumes that the processor does not execute encrypted memory (i.e. using on-the-fly decryption in hardware). </ins> <del> When an update gets aborted while the bootloader is decrypting the newly obtained image and swapping the blocks, the bootloader can restart where it left off.  This technique again offers robustness. </del> <ins> The ability to restart an interrupted firmware update is often a requirement for low-end IoT devices.  To fulfill this requirement it is necessary to chunk a firmware image into sectors and to encrypt each sector individually using a cipher that does not increase the size of the resulting ciphertext (i.e., by not adding an authentication tag after each encrypted block). </ins> <del> To accomplish this functionality, ciphers without integrity protection are used to encrypt the firmware image.  Integrity protection for the firmware image is, however, important and therefore the image digest defined in I-D.ietf-suit-manifest MUST be </del> <ins> When an update gets aborted while the bootloader is decrypting the newly obtained image and swapping the sectors, the bootloader can restart where it left off.  This technique offers robustness and better performance. For this purpose ciphers without integrity protection are used to encrypt the firmware image.  Integrity protection for the firmware image must, however, be provided and the the suit-parameter-image- digest, defined in Section 8.4.8.6 of I-D.ietf-suit-manifest, MUST be </ins> used. <del> I-D.housley-cose-aes-ctr-and-cbc registers several ciphers that do not offer integrity protection. </del> <ins> I-D.housley-cose-aes-ctr-and-cbc registers AES Counter mode (AES-CTR) and AES Cipher Block Chaining (AES-CBC) ciphers that do not offer integrity protection.  These ciphers are useful for the use cases that require firmware encryption on IoT devices.  For many other use cases where software packages, configuration information or personalization data needs to be encrypted, the use of Authenticated Encryption with Additional Data (AEAD) ciphers is preferred. The following sub-sections provide further information about the initialization vector (IV) selection for use with AES-CBC and AES-CTR in the firmware encryption context.  An IV MUST NOTE be re-used when the same key is used.  For this application, the IVs are not random but rather based on the slot/sector-combination in flash memory.  The text below assumes that the block-size of AES is (much) smaller than sector size.  The typical sector-size of flash memory is in the order of KiB.  Hence, multiple AES blocks need to be decrypted until an entire sector is completed. 8.1. In AES-CBC a single IV is used for encryption of firmware belonging to a single sector since individual AES blocks are chained toghether, as shown in aes-cbc.  The numbering of sectors in a slot MUST start with zero (0) and MUST increase by one with every sector till the end of the slot is reached.  The IV follows this numbering. For example, let us assume the slot size of a specific flash controller on an IoT device is 64 KiB, the sector size 4096 bytes (4 KiB) and AES-128-CBC uses an AES-block size of 128 bit (16 bytes). Hence, sector 0 needs 4096/16=256 AES-128-CBC operations using IV 0. If the firmware image fills the entire slot then that slot contains 16 sectors, i.e. IVs ranging from 0 to 15. 8.2. Unlike AES-CBC, AES-CTR uses an IV per AES operation.  Hence, when an image is encrypted using AES-CTR-128 or AES-CTR-256, the IV MUST start with zero (0) and MUST be incremented by one for each 16-byte plaintext block within the entire slot. Using the previous example with a slot size of 64 KiB, the sector size 4096 bytes and the AES plaintext block size of 16 byte requires IVs from 0 to 255 in the first sector and 16 * 256 IVs for the remaining sectors in the slot.  The last IV used to encrypt data in the slot is therefore </ins> 9.


Question:
Adding an example manifest using AES-KW in case where the Author knows the recipients (the Author and the Devices have the same pre-shared key).
This is a good example. I looked through it and it made sense to me.
In the firmware encryption draft we have defined an extension to the envelope that indicates what encryption parameters are applied to which component. Here is the CDDL: Currently the text provides no explanation or an example of how this linkage works.
This aspect is related to URL and to the mailing list discussion URL
This issue is also related to URL
With in PR , this issue is solved. Internet-Draft draft-ietf-suit-firmware-encryption-URL is now available. It is a work item of the Software Updates for Internet of Things (SUIT) WG of the IETF. Title: Encrypted Payloads in SUIT Manifests Authors: Hannes Tschofenig Russ Housley Brendan Moran David Brown Ken Takayama Name: draft-ietf-suit-firmware-encryption-URL Pages: 52 Dates: 2024-03-03 Abstract: This document specifies techniques for encrypting software, firmware, machine learning models, and personalization data by utilizing the IETF SUIT manifest. Key agreement is provided by ephemeral-static (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW). ES-DH uses public key cryptography while AES-KW uses a pre-shared key. Encryption of the plaintext is accomplished with conventional symmetric key cryptography. The IETF datatracker status page for this Internet-Draft is: URL There is also an HTMLized version available at: URL A diff from the previous version is available at: https://author-URL Internet-Drafts are also available by rsync at: URL

a digital signature), multiple recipients, encryption of manifests (in comparison to firmware images).]] <ins> The following manifests examplify how to deliver the encrypted firmware and its encryption info to the Devices. The examples are signed using the following ECDSA secp256r1 key: The corresponding public key can be used to verify these examples: Each example uses SHA256 as the digest function. 9.1. Diagnostic notation of the SUIT Manifest: In hex: </ins> 10. The algorithms described in this document assume that the party


Question: In Section 3 of the RFC, it states that the authenticator request includes those extensions allowed for the CertificateRequest message. However, this does not mean it could only includes them and other extensions could also be sent. In the TLS spec CertificateRequest explicitly states "Clients MUST ignore unrecognized extensions.", we should have the same here.

If an authenticator request is present, the extensions used to guide the construction of these messages are taken from the authenticator <del> request.  If the certificate_request_context from the authenticator request has already been used in the connection, then no authenticator should be constructed.  If there is no authenticator request, the extensions are chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request. In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </del> <ins> request.  Unrecognized extensions MUST be ignored.  If the certificate_request_context from the authenticator request has already been used in the connection, then no authenticator should be constructed.  If there is no authenticator request, the extensions are chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request.  In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </ins> 4.2.1.


Question:
This proposed text disallows specifying a flag extension where the response is a regular extension with content rather than a mere acknowledgment.
Well, I think of this as being the request extension. I can live with this if it's the WG consensus, but it seems like it would be useful to be able to say "I support largeish extension X" (we already have some such extensions) and it would be kind of sad if that took 4 bytes.
Seems strange to have to state this, but that's OK. Do you want to explain why? That is, because this results in a "response" extension appearing without a "request" extension, which is not permitted.

A Flags Extension for TLS 1.3 <del> draft-ietf-tls-tlsflags-09 </del> <ins> draft-ietf-tls-tlsflags-10 </ins> Abstract


Question:
This proposed text disallows specifying a flag extension where the response is a regular extension with content rather than a mere acknowledgment.
Well, I think of this as being the request extension. I can live with this if it's the WG consensus, but it seems like it would be useful to be able to say "I support largeish extension X" (we already have some such extensions) and it would be kind of sad if that took 4 bytes.
Seems strange to have to state this, but that's OK. Do you want to explain why? That is, because this results in a "response" extension appearing without a "request" extension, which is not permitted.

understands and supports the extension, but some extensions do not require this acknowledgement. <ins> For a flag that does require a response, the only proper response is the same flag in a flags extension.  This extension MUST NOT be used to specify extensions where the response is a proper extension with content. </ins> A flag proposed by the client in ClientHello (CH) that requires acknowledgement SHOULD be acknowledged in either ServerHello (SH), in EncryptedExtensions (EE), in Certificate (CT), or in


Question:
Addresses .
.Add some additional text to highlight that sig on server cert and DC can be different. from . Hi Sean, Thanks for the follow-up. I refreshed my memory as much as I could. Please see my responses in line. Yours, Daniel Sean Turner wrote: I think I would rather take the structure: 1 - Use case 2 - Problem description 3 - Solution I am fine with whatever fits best to you. Server operators often deploy TLS termination services in locations such as remote data centers or Content Delivery Networks (CDNs) where it may be difficult to detect key compromises. Short-lived certificates may be used to limit the exposure of keys in these cases. However, short-lived certificates need to be renewed more frequently than long-lived certificates. If an external CA is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificates and therefore a higher risk that an outage at a CA will negatively affect the uptime of the service. Typically, a TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or CA) [RFC8446 ] [RFC5280 ]. This organizational separation makes the TLS server operator dependent on the CA for some aspects of its operations, for example: Whenever the server operator wants to deploy a new certificate, it has to interact with the CA. The server operator can only use TLS signature schemes for which the CA will issue credentials. To reduce the dependency on external CAs, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own credentials within the scope of a certificate issued by an external CA. These credentials only enable the recipient of the delegation to speak for names that the CA has authorized. Furthermore, this mechanism allows the server to use modern signature algorithms such as Ed25519 [RFC8032 ] even if their CA does not support them. We will refer to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential" or "DC". I think my concern has been clarified by Ilari. It was resolved by your b). I am fine with both text. works for me. The text does not address my concern and will recap my perspective of the discussion. My initial comment was that the reference [KEYLESS] points to a solution that does not work with TLS 1.3 and currently the only effort compatible with TLS 1.3 is draft-mglt-lurk-tls13. I expect this reference to be mentioned and I do not see it in the text proposed text. If the intention with [KEYLESS] is to mention TLS Handshake Proxying techniques, then I argued that other mechanisms be mentioned and among others draft-mglt-lurk-tls12 and draft-mglt-lurk-tls13 that address different versions of TLS. This was my second concern and I do not see any of these references being mentioned. The way I understand your response is that the paper pointed out by [KEYLESS] is not Cloudflare's commercial product but instead a generic TLS Handshake proxying and that you propose to add a reference to an academic paper that discusses the LURK extension for TLS 1.2. I appreciate that other solutions - and in this case LURK, are being considered. I am wondering however why draft-mglt-lurk-tls12 is being replaced by an academic reference [REF2] and why draft-mglt-lurk-tls13 has been omitted. It seems that we are trying to avoid any reference of the work that is happening at the IETF. Is there anything I am missing ? My suggestion for the text OLD: (e.g., a PKCS interface or a remote signing mechanism [KEYLESS]) NEW: (e.g., a PKCS interface or a remote signing mechanism such as [draft-mglt-lurk-tls13] or [draft-mglt-lurk-tls12] ([LURK-TLS12]) or [KEYLESS]) with [KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake Proxying", IEEE TrustCom/BigDataSE/ISPA 2015, 2015. [LURK-TLS12] Boureanu, I., Migault, D., Preda, S., Alamedine, H.A., Mishra, S. Fieau, F., and M. Mannan, "LURK: Server-Controlled TLS Delegation”, IEEE TrustCom 2020, URL, 2020. [draft-mglt-lurk-tls12] IETF draft [draft-mglt-lurk-tls13] IETF draft It is unclear to me what is generic about the paper pointed by [KEYLESS] or [REF1]. In any case, for clarification, the paper clearly refers to Cloudflare commercial products as opposed to a generic mechanism, and this will remain whatever label will be used as a reference. Typically, Cloudflare co-authors the paper appears 12 times in the 8 page paper. The contribution section mentions: """ Our work focuses specifically on the TLS handshake proxying system implemented by CloudFlare in their Keyless SSL product [6], [7] """ The methodology mentions says: """ We tested TLS key proxying using CloudFlare’s implementation, which was implemented with the following three parts: """ """ The different scenarios were set up through CloudFlare’s control panel. In the direct handshake handshake scenario, the site is set up with no reverse proxy. In the scenario where the key is held by the edge server, the same certificate that was used on the origin is uploaded to CloudFlare and the reverse proxy is enabled for the site. """ Cloudflare appears in at least references URL CloudFlare Inc., “CloudFlare Keyless SSL,” Sep. 2014, URL N. Sullivan, “Keyless SSL: The nitty gritty technical details,” Sep. 2014, URL works for me. works for me seems clearer. I suspect earlier clarifications addressed this. thanks that it way clearer. Daniel Migault Ericsson

entire certificate and the delegated credential, cannot. Each delegated credential is bound to a specific signature <del> algorithm for use use in the TLS handshake (RFC8446 section 4.2.3).  This prevents them from being used with other, perhaps unintended signature algorithms. </del> <ins> algorithm for use in the TLS handshake (RFC8446 section 4.2.3). This prevents them from being used with other, perhaps unintended signature algorithms.  The signature algorithm bound to the delegated credential can be chosen independantly of the set of signature algorithms supported by the end-entity certificate. </ins> 3.2.


Question:
Need to address and directorate reviews.
Correction ARTART editorial are addressed via and .
and .
Also noted in ARTART review. Reviewer: Christian Amsüss Review result: Ready with Nits Thanks for this well-written document ART topics: The document does not touch on any of the typical ART review issues; times are relative in well understood units, and versioning, formal language (ASN.1, which is outside of my experience to check) and encoding infrastructure (struct) follows TLS practices. General comments: The introduction of this mechanism gives the impression of a band-aid applied to a PKI ecosystem that has accumulated many limitations as outlined in section The present solution appears good, but if there is ongoing work on the underlying issues (even experimentally), I'd appreciate a careful reference to it. Section 7.6 hints at the front end querying the back-end for creation of new DCs -- other than that, DC distribution (neither push- nor pull-based) is discussed. If there are any mechanisms brewing, I'd appreciate a reference as well. Please check: The IANA considerations list "delegated_credential" for CH, CR and CT messages. I did not find a reference in the text for Ct, only for CH and CR. Editorial comments: (p5) "result for the peer.." -- extraneous period. (p9, p15, p16) The "7 days" are introduced as the default for a profilable prarameter, but later used without further comment.
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tls-subcerts-?? Reviewer: Elwyn Davies Review Date: 2022-04-08 IETF LC End Date: 2022-04-08 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. Just a few editrial level nits. Major issues: None Minor issues: None. Nits/editorial comments: Abstract: The exact form of the abbreviation (D)TLS is not in the set of well-known abbreviations. I assume it is supposed to mean DTLS or TLS - This ought to be expanded on first use. Abstract: s/mechanism to to/mechanism to/ s1, para 2: CA is used before its expansion in para 3. s1, next to last para: "this document proposes" Hopefully when it becomes an RFC it will do more than propose. Suggest "this document introduces". s1, next to last para: "to speak for names" sounds a bit anthropomorphic to me, but I can't think of a simple alternative word. s1, last para: s/We will refer/This document refers/ [Not an academic paper!] s3.1, 2nd bullet: s/provide are not necessary/provide is not necessary/ s4, definition of expectedcertverify_algorithm: " Only signature algorithms allowed for use in CertificateVerify message are allowed." Does this need a reference to the place where the list of such algorithms is recorded? s4.1.1 and s4.1.2: In s4.1.1: "the client SHOULD ignore delegated credentials sent as extensions to any other certificate." I would have though this ought to be a MUST. There is an equivalent in s4.1.2. I am not sure what the client/server might do if it doesn't ignore the DC. s4.1.3, para 1: s/same way that is done/same way that it is done/ s4.2, para 1: s/We define/This docuent defines/ sS/s5.1: RFC conventions prefer not to have sections empty of text: Add something like: "The following operational consideration should be taken into consideration when using Delegated Certificates:"

The initiator uses information from the peer's certificate to verify the delegated credential and that the peer is asserting an expected identity, determining an authentication result for the <del> peer.. </del> <ins> peer. </ins> Peers accepting the delegated credential use it as the certificate key for the (D)TLS handshake.


Question: The 0-RTT key might differ between TLS versions (as demonstrated with the draft -20 changes). Be explicit about storing this version number since section 4.2.9 requires this information too.

the following additional information MUST be provisioned to both parties: <ins> The TLS version number for use with this PSK </ins> The cipher suite for use with this PSK The Application-Layer Protocol Negotiation (ALPN) protocol, if any


Question:
It has a proper definition in appendix A.4. Note though that RFC 4507 section 7 has allocated this value for the session_ticket/NewSessionTicket handshake type. This point may be moot if RFC 4507 has been integrated with TLS 1.3, in which case RFC 4507 should be added to the list of obsoleted RFCs.
The handshake packets in TLS 1.2 and earlier are numbered so that the HandshakeType for each of client and server is strictly increasing when packets arrive in correct order, and HandshakeType/10 indicates the flight number. This allows for using a simpler state-machine. The new handshake packets {server,client}keyshare break this convention by using numbers in the flight 2 range (17 & 18), while belonging in flight 1. This suggestion is to renumber them to eg clientkeyshare(5) and serverkeyshare(6)

draft-04 <ins> Renumber the new handshake messages to be somewhat more consistent with existing convention and to remove a duplicate registration. </ins> Remove renegotiation. draft-03


Question: "A client MUST provide a 'pskkeyexchangemodes' extension if it offers a 'preshared_key' extension."

"pre_shared_key" is REQUIRED for PSK key agreement. <ins> "psk_key_exchange_modes" is REQUIRED for PSK key agreement. </ins> A client is considered to be attempting to negotiate using this specification if the ClientHello contains a "supported_versions" extension with 0x0304 as the highest version number contained in its


Question:
It appears we should have included rules for populating a registry for the pskkeyexchange_modes extension.
Yes, an obvious oversight in our oversite. :) I approve.
+1
FWIW, +1
+1 to a new registry.
Yes, we should create a registry. But: We need to update the "this document defines a new registry" to match the new number of registries (two) the space of allowed values is only one byte, so we don't need to talk about "first byte"

rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and ed25519. <ins> TLS PskKeyExchangeMode Registry: Values with the first byte in the range 0-253 (decimal) are assigned via Specification Required RFC8126.  Values with the first byte 254 or 255 (decimal) are reserved for Private Use RFC8126.  This registry SHALL have a "Recommended" column.  The registry [shall be/ has been] initially populated psk_ke (0) and psk_dhe_ke (1).  Both SHALL be marked as "Recommended". </ins>


Question: The I-D checklist requires that updates and obsoletes be included in the abstract; thought RFC. I personally feel this is [redacted] stupid, but I do not think that we should risk a process appeal to fight this battle.

over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. <ins> This document updates RFCs 4492, 5705, and 6066 and it obsoletes RFCs 5077, 5246, and 6961. </ins> 1. RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this


Question:
While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)

an editorial update.  It contains updated text in areas which were found to be unclear as well as other editorial improvements.  In addition, it removes the use of the term "master" as applied to <del> secrets in favor of the term "main". </del> <ins> secrets in favor of the term "main" or shorter names where no term was neccessary. </ins> 1.3.


Question:
While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)

depend on the ServerHello and therefore has weaker guarantees. This is especially relevant if the data is authenticated either with TLS client authentication or inside the application protocol. <del> The same warnings apply to any use of the early_exporter_main_secret. </del> <ins> The same warnings apply to any use of the early_exporter_secret. </ins> 0-RTT data cannot be duplicated within a connection (i.e., the server will not process the same data twice for the same connection), and an


Question:
While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)

At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message.  This message creates a unique association between the ticket value and a secret <del> PSK derived from the resumption main secret (see cryptographic- </del> <ins> PSK derived from the resumption secret (see cryptographic- </ins> computations). The client MAY use this PSK for future handshakes by including the


Question:
While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)

server implementation declines all PSK identities with different SNI values, these two values are always the same. <del> Note: Although the resumption main secret depends on the client's second flight, a server which does not request certificate-based client authentication MAY compute the remainder of the transcript </del> <ins> Note: Although the resumption ecret depends on the client's second flight, a server which does not request certificate-based client authentication MAY compute the remainder of the transcript </ins> independently and then send a NewSessionTicket immediately upon sending its Finished rather than waiting for the client Finished. This might be appropriate in cases where the client is expected to