content deemed as morally or commercially harmful to companies or consumers in some jurisdictions SIDN2020. <del> There are typically three types of blocklist elements: Keyword, domain name, or Internet Protocol (IP) address.  Keyword and domain name blocking take place at the application level, e.g., HTTP, whereas IP blocking tends to take place using IP addresses in IPv4/ IPv6 headers.  The mechanisms for building up these blocklists vary. Censors can purchase from private industry "content control" software, such as SmartFilter, which lets censors filter traffic from broad categories they would like to block, such as gambling or pornography Knight-2005.  In these cases, these private services attempt to categorize every semi-questionable website as to allow for meta-tag blocking.  Similarly, they tune real-time content heuristic systems to map their assessments onto categories of objectionable content. </del>  Countries that are more interested in retaining specific political control typically have ministries or organizations that maintain 4.2.3.  Many governments pressure content providers to censor themselves, or provide the legal framework within which content distributors are incentivized to follow the content restriction preferences of agents political opinions in relation to the 2019 Hong Kong protests Victor- 2019.  See also discon. <del> 4.2.4. </del>  DPI (deep packet inspection) technically is any kind of packet analysis beyond IP address and port number and has become could use DPI to sort and categorically search gathered traffic using technologies such as NarusInsight Hepting-2011. <del> 4.2.4.1. In encrypted connections using Transport Layer Security (TLS), there may be servers that host multiple "virtual servers" at a given network address, and the client will need to specify in the (unencrypted) Client Hello message which domain name it seeks to connect to (so that the server can respond with the appropriate TLS certificate) using the Server Name Indication (SNI) TLS extension RFC6066.  Since SNI is often sent in the clear (as are the cert fields sent in response), censors and filtering software can use it (and response cert fields) as a basis for blocking, filtering, or impairment by dropping connections to domains that match prohibited content (e.g., bad.foo.example may be censored while good.foo.example is not) Shbair-2015.  There are undergoing standardization efforts in the TLS Working Group to encrypt SNI I-D.ietf-tls-sni-encryption I- D.ietf-tls-esni and recent research shows promising results in the use of encrypted SNI in the face of SNI-based filtering Chai-2019. Domain fronting has been one popular way to avoid identification by censors Fifield-2015.  To avoid identification by censors, applications using domain fronting put a different domain name in the SNI extension than in the Host: header, which is protected by HTTPS. The visible SNI would indicate an unblocked domain, while the blocked domain remains hidden in the encrypted application header.  Some encrypted messaging services relied on domain fronting to enable their provision in countries employing SNI-based filtering.  These services used the cover provided by domains for which blocking at the domain level would be undesirable to hide their true domain names. However, the companies holding the most popular domains have since reconfigured their software to prevent this practice.  It may be possible to achieve similar results using potential future options to encrypt SNI. Tradeoffs: Some clients do not send the SNI extension (e.g., clients that only support versions of SSL and not TLS), rendering this method ineffective.  In addition, this technique requires deep packet inspection techniques that can be computationally and infrastructurally expensive and improper configuration of an SNI- based block can result in significant overblocking, e.g., when a second-level domain like populardomain.example is inadvertently blocked.  In the case of encrypted SNI, pressure to censor may transfer to other points of intervention, such as content and application providers. Empirical Examples: There are many examples of security firms that offer SNI-based filtering products Trustwave-2015 Sophos-2015 Shbair- 2015, and the governments of China, Egypt, Iran, Qatar, South Korea, Turkey, Turkmenistan, and the UAE all do widespread SNI filtering or blocking OONI-2018 OONI-2019 NA-SK-2019 CitizenLab-2018 Gatlan-2019 Chai-2019 Grover-2019 Singh-2019. </del> 4.3. 4.3.1. traffic of censorship circumvention tools appear indistinguishable from other kinds of traffic Tor-2020.  Empirical Examples: Protocol identification can be easy to detect if it is conducted in real time and only a particular protocol is blocked, but some types of protocol identification, like active unusable Anonymous-2007 and by China to identify and block Tor relays Winter-2012.  Protocol identification has also been used for traffic management, such as the 2007 case where Comcast in the United States <del> used RST injection to interrupt BitTorrent Traffic Winter-2012. </del>  5. is a specific type of packet injection attack that is used to interrupt an established stream by sending RST packets to both sides of a TCP connection; as each receiver thinks the other has dropped <del> the connection, the session is terminated.  QUIC is not vulnerable to these types of injection attacks once the connection has been setup, but is vulnerable during setup (See I-D.ietf-quic-transport for more details). </del>  Trade-offs: Although ineffective against non-TCP protocols (QUIC, IPSec), RST Packet Injection has a few advantages that make it about the TCP stream they are injecting into, they can simply enumerate all ~70000 possible windows; this is particularly useful for interrupting encrypted/obfuscated protocols such as SSH or Tor <del> Gilad.  RST Packet Injection relies on a stateful network, making it useless against UDP connections.  RST Packet Injection is among the most popular censorship techniques used today given its versatile nature and effectiveness against all types of TCP traffic.  Recent research shows that a TCP RST packet injection attack can even work in the case of an off-path attacker Cao-2016. </del>  Empirical Examples: RST Packet Injection, as mentioned above, is most often paired with identification techniques that require splitting, India was the country that saw the largest number of internet shutdowns per year in 2016 and 2017 Dada-2017.  6. 6.1.

Hi team - Here's a pull request with some additional text and information to add to the RFC. Please let me know if there are things I should change or add or remove or fix - totally open to feedback! My changes are the following: Added text towards additional forms of TLS censorship (and citations for them): ESNI censorship, server certificate censorship, omitted SNI censorship Added text about residual censorship Added text about censorship in depth Added text about additional keyword blocking dynamics, there's been some recent research on this Added text about protocol filtering (such as Iran's protocol filter) Added some additional citations for various forms of censorship I'd be happy to break this up into multiple PRs if that's easier as well.
Kevin, if you can rebase your commits on top of the latest version, I'm happy to merge this PR. Thank you for your work on it!
Hi NAME - Just wanted to give this a bump as I close this tab. Let me know if there's any other work that should be added!

content deemed as morally or commercially harmful to companies or consumers in some jurisdictions SIDN2020.  <ins> There are typically a few types of blocklist elements: Keyword, domain name, protocol, or Internet Protocol (IP) address.  Keyword and domain name blocking take place at the application level, e.g., HTTP; protocol blocking often occurs using Deep Packet Inspection to identify a forbidden protocol; IP blocking tends to take place using IP addresses in IPv4/IPv6 headers.  Some censors also use the presence of certain keywords to enable more aggressive blocklists Rambert-2021 or to be more permissive with content Knockel-2021. The mechanisms for building up these blocklists vary.  Censors can purchase from private industry "content control" software, such as SmartFilter, which lets censors filter traffic from broad categories they would like to block, such as gambling or pornography Knight- 2005.  In these cases, these private services attempt to categorize every semi-questionable website as to allow for meta-tag blocking. Similarly, they tune real-time content heuristic systems to map their assessments onto categories of objectionable content. </ins> Countries that are more interested in retaining specific political control typically have ministries or organizations that maintain 4.2.3. <ins> Similar to HTTP, censors have deployed a variety of techniques towards censoring Transport Layer Security (TLS) (and by extension HTTPS).  Most of these techniques relate to the Server Name Indication (SNI) field, including censoring SNI, Encrypted SNI, or omitted SNI.  Censors can also censor HTTPS content via server certificates. 4.2.3.1. In encrypted connections using TLS, there may be servers that host multiple "virtual servers" at a given network address, and the client will need to specify in the (unencrypted) Client Hello message which domain name it seeks to connect to (so that the server can respond with the appropriate TLS certificate) using the Server Name Indication (SNI) TLS extension RFC6066.  Since SNI is often sent in the clear (as are the cert fields sent in response), censors and filtering software can use it (and response cert fields) as a basis for blocking, filtering, or impairment by dropping connections to domains that match prohibited content (e.g., bad.foo.example may be censored while good.foo.example is not) Shbair-2015.  There are undergoing standardization efforts in the TLS Working Group to encrypt SNI I-D.ietf-tls-sni-encryption I-D.ietf-tls-esni and recent research shows promising results in the use of encrypted SNI in the face of SNI-based filtering Chai-2019 in some countries. Domain fronting has been one popular way to avoid identification by censors Fifield-2015.  To avoid identification by censors, applications using domain fronting put a different domain name in the SNI extension than in the Host: header, which is protected by HTTPS. The visible SNI would indicate an unblocked domain, while the blocked domain remains hidden in the encrypted application header.  Some encrypted messaging services relied on domain fronting to enable their provision in countries employing SNI-based filtering.  These services used the cover provided by domains for which blocking at the domain level would be undesirable to hide their true domain names. However, the companies holding the most popular domains have since reconfigured their software to prevent this practice.  It may be possible to achieve similar results using potential future options to encrypt SNI. Tradeoffs: Some clients do not send the SNI extension (e.g., clients that only support versions of SSL and not TLS), rendering this method ineffective (see omitsni).  In addition, this technique requires deep packet inspection techniques that can be computationally and infrastructurally expensive and improper configuration of an SNI- based block can result in significant overblocking, e.g., when a second-level domain like populardomain.example is inadvertently blocked.  In the case of encrypted SNI, pressure to censor may transfer to other points of intervention, such as content and application providers. Empirical Examples: There are many examples of security firms that offer SNI-based filtering products Trustwave-2015 Sophos-2015 Shbair- 2015, and the governments of China, Egypt, Iran, Qatar, South Korea, Turkey, Turkmenistan, and the UAE all do widespread SNI filtering or blocking OONI-2018 OONI-2019 NA-SK-2019 CitizenLab-2018 Gatlan-2019 Chai-2019 Grover-2019 Singh-2019. 4.2.3.2. With the data leakage present with the SNI field, a natural response is to encrypt it, which is forthcoming in TLS 1.3 with Encrypted Client Hello (ECH).  Prior to ECH, the Encrypted SNI (ESNI) extension is available to prevent the data leakage caused by SNI, which encrypts only the SNI field.  Unfortunately, censors can target connections that use the ESNI extension specifically for censorship. This guarantees overblocking for the censor, but can be worth the cost if ESNI is not yet widely deployed within the country. Encrypted Client Hello (ECH) is the emerging standard for protecting the entire TLS Client Hello, but it is not yet widely deployed. Tradeoffs: The cost to censoring Encrypted SNI (ESNI) is significantly higher than SNI to a censor, as the censor can no longer target censorship to specific domains and guarantees over- blocking.  In these cases, the censor uses the over-blocking to discourage the use of ESNI entirely. Empirical Examples: In 2020, China began censoring all uses of Encrypted ESNI (ESNI) Bock-2020b, even for innocuous connections. The censorship mechanism for China's ESNI censorship differs from how China censors SNI-based connections, suggesting that new middleboxes were deployed specifically to target ESNI connections. 4.2.3.3. Researchers have observed that some clients omit the SNI extension entirely.  This omitted-SNI approach limits the information available to a censor.  Like with ESNI, censors can choose to block connections that omit the SNI, though this too risks over-blocking. Tradeoffs: The approach of censoring all connections that omit the SNI field is guaranteed to over-block, though connections that omit the SNI field should be relatively rare in the wild. Empirical Examples: In the past, researchers have observed censors in Russia blocking connections that omit the SNI field Bock-2020b. 4.2.3.4. During the TLS handshake after the TLS Client Hello, the server will respond with the TLS certificate.  This certificate also contains the domain the client is trying to access, creating another avenue that censors can use to perform censorship.  This technique will not work in TLS 1.3, as the certificate will be encrypted. Tradeoffs: Censoring based on the server certificate requires deep packet inspection techniques that can be more computationally expensive compared to other methods.  Additionally, the certificate is sent later in the TLS Handshake compared to the SNI field, forcing the censor to track the connection for longer. Empirical Examples: Researchers have observed the Reliance Jio ISP in India using certificate response fields to censor connections Satija- 2021. 4.2.4. </ins> Many governments pressure content providers to censor themselves, or provide the legal framework within which content distributors are incentivized to follow the content restriction preferences of agents political opinions in relation to the 2019 Hong Kong protests Victor- 2019.  See also discon.  <ins> 4.2.5. </ins> DPI (deep packet inspection) technically is any kind of packet analysis beyond IP address and port number and has become could use DPI to sort and categorically search gathered traffic using technologies such as NarusInsight Hepting-2011.  4.3. 4.3.1. traffic of censorship circumvention tools appear indistinguishable from other kinds of traffic Tor-2020. <ins> Censors have also used protocol identification in the past in an 'allowlist' filtering capacity, such as by only allowing specific, pre-vetted protocols to be used and blocking any unrecognized protocols Bock-2020.  These protocol filtering approaches can also lead to over-blocking if the allowed lists of protocols is too small or incomplete, but can be cheap to implement, as many standard 'allowed' protocols are simple to identify (such as HTTP). </ins> Empirical Examples: Protocol identification can be easy to detect if it is conducted in real time and only a particular protocol is blocked, but some types of protocol identification, like active unusable Anonymous-2007 and by China to identify and block Tor relays Winter-2012.  Protocol identification has also been used for traffic management, such as the 2007 case where Comcast in the United States  <ins> used RST injection to interrupt BitTorrent Traffic Winter-2012.  In 2020, Iran deployed an allowlist protocol filter, which only allowed three protocols to be used (DNS, TLS, and HTTP) on specific ports and censored any connection it could not identify Bock-2020. 4.4. Another feature of some modern censorship systems is residual censorship, a punitive form of censorship whereby after a censor disrupts a forbidden connection, the censor continues to target subsequent connections, even if they are innocuous Bock-2021. Residual censorship can take many forms and often relies on the methods of technical interference described in the next section. An important facet of residual censorship is precisely what the censor continues to block after censorship is initially triggered. There are three common options available to an adversary: 2-tuple (client IP, server IP), 3-tuple (client IP, server IP+port), or 4-tuple (client IP+port, server IP+port).  Future connections that match the tuple of information the censor records will be disrupted Bock-2021. Residual censorship can sometimes be difficult to identify and can often complicate censorship measurement. Trade-offs: The impact of residual censorship is to provide users with further discouragement from trying to access forbidden content, though it is not clear how successful it is at accomplishing this. Empirical Examples: China has used 3-tuple residual censorship in conjunction with their HTTP censorship for years and researchers have reported seeing similar residual censorship for HTTPS.  China seems to use a mix of 3-tuple and 4-tuple residual censorship for their censorship of HTTPS with ESNI.  Some censors that perform censorship via packet dropping often accidentally implement 4-tuple residual censorship, including Iran and Kazakhstan Bock-2021. </ins> 5. is a specific type of packet injection attack that is used to interrupt an established stream by sending RST packets to both sides of a TCP connection; as each receiver thinks the other has dropped  <ins> the connection, the session is terminated. QUIC is not vulnerable to these types of injection attacks once the connection has been setup, but is vulnerable during setup (See I- D.ietf-quic-transport for more details). </ins> Trade-offs: Although ineffective against non-TCP protocols (QUIC, IPSec), RST Packet Injection has a few advantages that make it about the TCP stream they are injecting into, they can simply enumerate all ~70000 possible windows; this is particularly useful for interrupting encrypted/obfuscated protocols such as SSH or Tor  <ins> Gilad.  Some censorship evasion systems work by trying to confuse the censor into tracking incorrect information, rendering their RST Packet Injection useless Khattak-2013, Wang-2017, Li-2017, Bock-2019, Wang-2020. RST Packet Injection relies on a stateful network, making it useless against UDP connections.  RST Packet Injection is among the most popular censorship techniques used today given its versatile nature and effectiveness against all types of TCP traffic.  Recent research shows that a TCP RST packet injection attack can even work in the case of an off-path attacker Cao-2016. </ins> Empirical Examples: RST Packet Injection, as mentioned above, is most often paired with identification techniques that require splitting, India was the country that saw the largest number of internet shutdowns per year in 2016 and 2017 Dada-2017. <ins> 5.3.3. Often, censors implement multiple techniques in tandem, creating "censorship in depth".  Censorship in depth can take many forms; some censors block the same content through multiple techniques (such as blocking a domain by DNS, IP blocking, and HTTP simultaneously), some deploy parallel systems to improve censorship reliability (such as deploying multiple different censorship systems to block the same domain), and others can use complimentary systems to limit evasion (such as by blocking unwanted protocols entirely, forcing users to use other filtered protocols). Trade-offs: Censorship in depth can be attractive for censors to deploy, as it offers additional guarantees about censorship: even if someone evades one type of censorship, they may still be blocked by another.  The main drawback to this approach is the cost to initial deployment, as it requires the system to deploy multiple censorship systems in tandem. Empirical Examples: Censorship in depth is present in many large censoring nation states today.  Researchers have observed China has deployed significant censorship in depth, often censoring the same resource across multiple protocols Chai-2019, Bock-2020b or deploying additional censorship systems to censor the same content and protocol Bock-2021b.  Iran also has deployed a complimentary protocol filter to limit which protocols can be used on certain ports, forcing users to rely on protocols their censorship system can filter Bock-2020. </ins> 6. 6.1.


HTTPS).  Most of these techniques relate to the Server Name Indication (SNI) field, including censoring SNI, Encrypted SNI, or omitted SNI.  Censors can also censor HTTPS content via server <del> certificates. </del>  4.2.3.1. In encrypted connections using TLS, there may be servers that host multiple "virtual servers" at a given network address, and the client <del> will need to specify in the (unencrypted) Client Hello message which domain name it seeks to connect to (so that the server can respond with the appropriate TLS certificate) using the Server Name Indication (SNI) TLS extension RFC6066.  Since SNI is often sent in the clear (as are the cert fields sent in response), censors and filtering software can use it (and response cert fields) as a basis for blocking, filtering, or impairment by dropping connections to domains that match prohibited content (e.g., bad.foo.example may be censored while good.foo.example is not) Shbair-2015.  There are undergoing standardization efforts in the TLS Working Group to encrypt SNI I-D.ietf-tls-sni-encryption I-D.ietf-tls-esni and recent research shows promising results in the use of encrypted SNI in the face of SNI-based filtering Chai-2019 in some countries. </del>  Domain fronting has been one popular way to avoid identification by censors Fifield-2015.  To avoid identification by censors, that only support versions of SSL and not TLS), rendering this method ineffective (see omitsni).  In addition, this technique requires deep packet inspection techniques that can be computationally and <del> infrastructurally expensive and improper configuration of an SNI- based block can result in significant overblocking, e.g., when a </del>  second-level domain like populardomain.example is inadvertently blocked.  In the case of encrypted SNI, pressure to censor may transfer to other points of intervention, such as content and 2015, and the governments of China, Egypt, Iran, Qatar, South Korea, Turkey, Turkmenistan, and the UAE all do widespread SNI filtering or blocking OONI-2018 OONI-2019 NA-SK-2019 CitizenLab-2018 Gatlan-2019 <del> Chai-2019 Grover-2019 Singh-2019. </del>  4.2.3.2. most cases can be used to infer the domain being visited Patil-2019. Port is useful for allowlisting certain applications.  Trade-offs: header identification is popular due to its simplicity, availability, and robustness. thousands of IP addresses.  Despite these limitations, IP blocking is extremely effective because the user needs to proxy their traffic through another destination to circumvent this type of <del> identification. </del>  Port-blocking is generally not useful because many types of content share the same port and it is possible for censored applications to used RST injection to interrupt BitTorrent Traffic Winter-2012.  In 2020, Iran deployed an allowlist protocol filter, which only allowed three protocols to be used (DNS, TLS, and HTTP) on specific ports and <del> censored any connection it could not identify Bock-2020. </del>  4.4. as one of its primary mechanisms of technical censorship Ensafi-2013. Iran has also used Packet Dropping as the mechanisms for throttling SSH Aryan-2012.  These are but two examples of a ubiquitous <del> censorship practice. </del>  5.2.3. the connection, the session is terminated. QUIC is not vulnerable to these types of injection attacks once the <del> connection has been setup, but is vulnerable during setup (See I- D.ietf-quic-transport for more details). </del>  Trade-offs: Although ineffective against non-TCP protocols (QUIC, IPSec), RST Packet Injection has a few advantages that make it

This pull request adds findings about QUIC censorship. The changes are the following: References to my 2021 paper and 2022 OTF blog post on QUIC and HTTP/3 censorship. Details about QUIC's initial encryption of the ClientHello with a non-secret key. This initial encryption differs from traditional TLS over TCP. Requirements for the censor to apply Deep Packet Inspection to QUIC packets. Case of SNI blocking of QUIC traffic in Russia. Shallow packet inspection of QUIC traffic: IP blocking, UDP endpoint blocking, protocol blocking. Packet dropping as only observed interference method. Considerations on packet injection and connection reset in the context of QUIC.

HTTPS).  Most of these techniques relate to the Server Name Indication (SNI) field, including censoring SNI, Encrypted SNI, or omitted SNI.  Censors can also censor HTTPS content via server  <ins> certificates.  Note that TLS 1.3 acts as a security component of QUIC. </ins> 4.2.3.1. In encrypted connections using TLS, there may be servers that host multiple "virtual servers" at a given network address, and the client  <ins> will need to specify in the Client Hello message which domain name it seeks to connect to (so that the server can respond with the appropriate TLS certificate) using the Server Name Indication (SNI) TLS extension RFC6066.  The Client Hello message is unencrypted for TCP-based TLS.  When using QUIC, the Client Hello message is encrypted but its confidentiality is not effectively protected because the initial encryption keys are derived using a value that is visible on the wire.  Since SNI is often sent in the clear (as are the cert fields sent in response), censors and filtering software can use it (and response cert fields) as a basis for blocking, filtering, or impairment by dropping connections to domains that match prohibited content (e.g., bad.foo.example may be censored while good.foo.example is not) Shbair-2015.  There are undergoing standardization efforts in the TLS Working Group to encrypt SNI I- D.ietf-tls-sni-encryption I-D.ietf-tls-esni and recent research shows promising results in the use of encrypted SNI in the face of SNI- based filtering Chai-2019 in some countries. </ins> Domain fronting has been one popular way to avoid identification by censors Fifield-2015.  To avoid identification by censors, that only support versions of SSL and not TLS), rendering this method ineffective (see omitsni).  In addition, this technique requires deep packet inspection techniques that can be computationally and  <ins> infrastructurally expensive, especially when applied to QUIC where deep packet inspection requires key extraction and decryption of the Client Hello in order to read the SNI.  Improper configuration of an SNI-based block can result in significant overblocking, e.g., when a </ins> second-level domain like populardomain.example is inadvertently blocked.  In the case of encrypted SNI, pressure to censor may transfer to other points of intervention, such as content and 2015, and the governments of China, Egypt, Iran, Qatar, South Korea, Turkey, Turkmenistan, and the UAE all do widespread SNI filtering or blocking OONI-2018 OONI-2019 NA-SK-2019 CitizenLab-2018 Gatlan-2019  <ins> Chai-2019 Grover-2019 Singh-2019.  SNI blocking against QUIC traffic has been first observed in Russia in March 2022 Elmenhorst-2022. </ins> 4.2.3.2. most cases can be used to infer the domain being visited Patil-2019. Port is useful for allowlisting certain applications. <ins> Combining IP address, port and protocol information found in the transport header, shallow packet inspection can be used by a censor to identify specific TCP or UDP endpoints.  UDP endpoint blocking has been observed in the context of QUIC blocking Elmenhorst-2021. </ins> Trade-offs: header identification is popular due to its simplicity, availability, and robustness. thousands of IP addresses.  Despite these limitations, IP blocking is extremely effective because the user needs to proxy their traffic through another destination to circumvent this type of  <ins> identification.  In addition, IP blocking is effective against all protocols above IP, e.g.  TCP and QUIC. </ins> Port-blocking is generally not useful because many types of content share the same port and it is possible for censored applications to used RST injection to interrupt BitTorrent Traffic Winter-2012.  In 2020, Iran deployed an allowlist protocol filter, which only allowed three protocols to be used (DNS, TLS, and HTTP) on specific ports and  <ins> censored any connection it could not identify Bock-2020.  In 2022, Russia seemed to have used protocol identification to block most HTTP/3 connections Elmenhorst-2022. </ins> 4.4. as one of its primary mechanisms of technical censorship Ensafi-2013. Iran has also used Packet Dropping as the mechanisms for throttling SSH Aryan-2012.  These are but two examples of a ubiquitous  <ins> censorship practice.  Notably, packet dropping during the handshake or working connection is the only interference technique observed for QUIC traffic so far, e.g. in India, Iran, Russia and Uganda Elmenhorst-2022. </ins> 5.2.3. the connection, the session is terminated. QUIC is not vulnerable to these types of injection attacks once the  <ins> connection has been setup.  While QUIC implements a stateless reset mechanism, such a reset is only accepted by a peer if the packet ends in a previously issued stateless reset token which is hard to guess. During the handshake, QUIC only provides effective protection against off-path attackers but is vulnerable to injection attacks by attackers that have parsed prior packets.  (See I-D.ietf-quic- transport for more details.) </ins> Trade-offs: Although ineffective against non-TCP protocols (QUIC, IPSec), RST Packet Injection has a few advantages that make it


This key exchange algorithm is the same as ECDHE_ECDSA except that the server's certificate MUST contain an RSA public key authorized for signing, and that the signature in the ServerKeyExchange message <del> must be computed with the corresponding RSA private key.  The server certificate MUST be signed with RSA. </del>  2.3. resultant shared secret as the premaster secret.  All ECDH calculations are performed as specified in alg_computes. <del> Note that while the ECDHE_ECDSA and ECDHE_RSA key exchange algorithms require the server's certificate to be signed with a particular signature scheme, this specification (following the similar cases of DHE_DSS, and DHE_RSA in the TLS base documents) does not impose restrictions on signature schemes used elsewhere in the certificate chain.  (Often such restrictions will be useful, and it is expected that this will be taken into account in certification authorities' signing practices.  However, such restrictions are not strictly required in general: Even if it is beyond the capabilities of a client to completely validate a given chain, the client may be able to validate the server's certificate by relying on a trusted certification authority whose certificate appears as one of the intermediate certificates in the chain.) </del>  3. 3.1. To use this authentication mechanism, the client MUST possess a <del> certificate containing an ECDSA-capable public key and signed with ECDSA. </del>  The client proves possession of the private key corresponding to the certified key by including a signature in the CertificateVerify

TLS 1.1 and earlier required the signature algorithm in the certificate to match that of the public key. TLS 1.2 removed this restriction. Since RFC 4492 predated TLS 1.2 it reflected the same restriction. Here we remove it.

This key exchange algorithm is the same as ECDHE_ECDSA except that the server's certificate MUST contain an RSA public key authorized for signing, and that the signature in the ServerKeyExchange message  <ins> must be computed with the corresponding RSA private key. </ins> 2.3. resultant shared secret as the premaster secret.  All ECDH calculations are performed as specified in alg_computes.  <ins> This specification does not impose restrictions on signature schemes used anywhere in the certificate chain.  The previous version of this document required the signatures to match, but this restriction, originating in previous TLS versions is lifted here as it had been in RFC 5246. </ins> 3. 3.1. To use this authentication mechanism, the client MUST possess a  <ins> certificate containing an ECDSA-capable public key. </ins> The client proves possession of the private key corresponding to the certified key by including a signature in the CertificateVerify


5.1.1. <del> RFC 4492 defined 25 different curves in the NamedCurve registry for use in TLS.  Only three have seen any use.  This specification is deprecating the rest (with numbers 1-22).  This specification also deprecates the explicit curves with identifiers 0xFF01 and 0xFF02. It also adds the new curves defined in CFRG-Curves and CFRG-EdDSA. The end result is as follows: </del>  Note that other specification have since added other values to this enumeration. RFC4492, the predecessor of this document has already defined the IANA registries for the following: <del> NamedCurve </del>  ECPointFormat ECCurveType For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight <del> values (ECPointFormat and ECCurveType) reserved for Private Use.  Any additional assignments require IETF Review. </del>  <del> NOTE: IANA, please update the registries to reflect the new policy name. </del>  NOTE: RFC editor please delete these two notes prior to publication.

See Sean Turner's message IETF review is too onerous - use "specification required" instead.

5.1.1.  <ins> RFC 4492 defined 25 different curves in the NamedCurve registry (now renamed the "Supported Groups" registry, although the enumeration below is still named NamedCurve) for use in TLS.  Only three have seen much use.  This specification is deprecating the rest (with numbers 1-22).  This specification also deprecates the explicit curves with identifiers 0xFF01 and 0xFF02.  It also adds the new curves defined in CFRG-Curves and CFRG-EdDSA.  The end result is as follows: </ins> Note that other specification have since added other values to this enumeration. RFC4492, the predecessor of this document has already defined the IANA registries for the following:  <ins> Supported Groups </ins> ECPointFormat ECCurveType For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight  <ins> values (ECPointFormat and ECCurveType) reserved for Private Use.  The policy for any additional assignments is "Specification Required". The previous version of this document required IETF review. </ins>  <ins> NOTE: IANA, please update the registries to reflect the new policy. </ins> NOTE: RFC editor please delete these two notes prior to publication.


class of explicitly defined curves.  The named curves secp256r1, secp384r1, and secp521r1 are specified in SEC 2 SECG-SEC2.  These curves are also recommended in ANSI X9.62 ANSI.X9-62.2005 and FIPS <del> 186-4 FIPS.186-4.  Curve25519 and Curve448 are defined in CFRG- Curves.  Ed25519 and Ed448 are signature-only curves defined in CFRG- EdDSA.  Values 0xFE00 through 0xFEFF are reserved for private use. </del>  The NamedCurve name space is maintained by IANA.  See iana for information on how new value assignments are added. This byte string may represent an elliptic curve point in uncompressed or compressed format; it MUST conform to what the client has requested through a Supported Point Formats Extension if this <del> extension was used.  For the Curve25519 and Curve448 curves, the only valid representation is the one specified in CFRG-Curves - a 32- or </del>  56-octet representation of the u value of the point.  This structure MUST NOT be used with Ed25519 and Ed448 public keys. Specifies a recommended set of elliptic curve domain parameters.  All those values of NamedCurve are allowed that refer to a curve capable of Diffie-Hellman.  With the deprecation of the explicit curves, this <del> now includes all values of NamedCurve except Ed25519(TBD3) and Ed448(TBD4). </del>  Specifies the elliptic curve domain parameters associated with the ECDH public key. or RSA_fixed_ECDH client authentication mechanism.) Contains the client's ephemeral ECDH public key as a byte string ECPoint.point, which may represent an elliptic curve point in <del> uncompressed or compressed format.  Curves Ed25519 and Ed448 MUST NOT be used.  Here, the format MUST conform to what the server has requested through a Supported Point Formats Extension if this extension was used, and MUST be uncompressed if this extension was not used. </del>  Actions of the sender: SECG-SEC2 or in CFRG-EdDSA. EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the <del> Ed25519 curve, and Ed448 and Ed448ph keys MUST use the Ed448 curve. Curves Curve25519, Curve448, Ed25519 and Ed448 MUST NOT be used for ECDSA. </del>  5.10. future TLS versions or new TLS extensions introduced in the future may vary this computation.) <del> An ECDHE key exchange using Curve25519 goes as follows.  Each party picks a secret key d uniformly at random and computes the corresponding public key x = Curve25519(d, G).  Parties exchange their public keys and compute a shared secret as x_S = Curve25519(d, x_peer).  ECDHE for Curve448 works similarily, replacing Curve25519 with Curve448.  The derived shared secret is used directly as the premaster secret, which is always exactly 32 bytes when ECDHE with Curve25519 is used and 56 bytes when ECDHE with Curve448 is used. </del>  All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result private key, to the point that they may recover the entire private key in a few requests, if that key is not really ephemeral. <del> Curve25519 was designed in a way that the result of Curve25519(x, d) will never reveal information about d, provided it was chosen as prescribed, for any value of x (the same holds true for Curve448). </del>  Let's define legitimate values of x as the values that can be <del> obtained as x = Curve25519(G, d') for some d, and call the other values illegitimate.  The definition of the Curve25519 function shows that legitimate values all share the following property: the high- order bit of the last byte is not set (for Ed448, any bit can be set). </del>  <del> Since there are some implementation of the Curve25519 function that </del>  impose this restriction on their input and others that don't, <del> implementations of Curve25519 in TLS SHOULD reject public keys when the high-order bit of the last byte is set (in other words, when the </del>  value of the leftmost byte is greater than 0x7F) in order to prevent implementation fingerprinting. Other than this recommended check, implementations do not need to ensure that the public keys they receive are legitimate: this is not <del> necessary for security with Curve25519. </del>  6. IANA, please update these two registries to refer to this document. IANA is requested to assign four values from the NamedCurve registry <del> with names Curve25519(TBD1), Curve448(TBD2), Ed25519(TBD3) and Ed448(TBD4) with this document as reference. </del>  IANA is requested to assign one value from SignatureAlgorithm Registry with name eddsa(TBD5) with this document as reference.

Replace uses of Curve25519 with X25519 (and similarly with 448-bit one). Also add zero checks as required by CFRG-CURVES. Because of problems with TLS 1.2 key exchange, omitting these checks leads to security issues.
Renamed the curves to be consistent with what got merged into TLS 1.3 spec

class of explicitly defined curves.  The named curves secp256r1, secp384r1, and secp521r1 are specified in SEC 2 SECG-SEC2.  These curves are also recommended in ANSI X9.62 ANSI.X9-62.2005 and FIPS  <ins> 186-4 FIPS.186-4. ecdh_x25519 and ecdh_x448 are defined in CFRG- Curves. eddsa_ed25519 and eddsa_ed448 are signature-only curves defined in CFRG-EdDSA.  Values 0xFE00 through 0xFEFF are reserved for private use. </ins> The NamedCurve name space is maintained by IANA.  See iana for information on how new value assignments are added. This byte string may represent an elliptic curve point in uncompressed or compressed format; it MUST conform to what the client has requested through a Supported Point Formats Extension if this  <ins> extension was used.  For the X25519 and X448 curves, the only valid representation is the one specified in CFRG-Curves - a 32- or </ins> 56-octet representation of the u value of the point.  This structure MUST NOT be used with Ed25519 and Ed448 public keys. Specifies a recommended set of elliptic curve domain parameters.  All those values of NamedCurve are allowed that refer to a curve capable of Diffie-Hellman.  With the deprecation of the explicit curves, this  <ins> now includes all values of NamedCurve except eddsa_ed25519(TBD3) and eddsa_ed448(TBD4). </ins> Specifies the elliptic curve domain parameters associated with the ECDH public key. or RSA_fixed_ECDH client authentication mechanism.) Contains the client's ephemeral ECDH public key as a byte string ECPoint.point, which may represent an elliptic curve point in  <ins> uncompressed or compressed format.  Curves eddsa_ed25519 and eddsa_ed448 MUST NOT be used here.  Here, the format MUST conform to what the server has requested through a Supported Point Formats Extension if this extension was used, and MUST be uncompressed if this extension was not used. </ins> Actions of the sender: SECG-SEC2 or in CFRG-EdDSA. EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the  <ins> eddsa_ed25519 curve, and Ed448 and Ed448ph keys MUST use the eddsa_ed448 curve.  Curves ecdh_x25519, ecdh_x448, eddsa_ed25519 and eddsa_ed448 MUST NOT be used for ECDSA. </ins> 5.10. future TLS versions or new TLS extensions introduced in the future may vary this computation.)  <ins> An ECDHE key exchange using X25519 (curve ecdh_x25519) goes as follows: Each party picks a secret key d uniformly at random and computes the corresponding public key x = X25519(d, G).  Parties exchange their public keys, and compute a shared secret as x_S = X25519(d, x_peer).  If either party obtains all-zeroes x_S, it MUST abort the handshake (as required by definition of X25519 and X448). ECDHE for X448 works similarily, replacing X25519 with X448, and ecdh_x25519 with ecdh_x448.  The derived shared secret is used directly as the premaster secret, which is always exactly 32 bytes when ECDHE with X25519 is used and 56 bytes when ECDHE with X448 is used. </ins> All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result private key, to the point that they may recover the entire private key in a few requests, if that key is not really ephemeral.  <ins> X25519 was designed in a way that the result of X25519(x, d) will never reveal information about d, provided it was chosen as prescribed, for any value of x (the same holds true for X448). All-zeroes output from X25519 or X448 MUST NOT be used for premaster secret (as required by definition of X25519 and X448).  If the premaster secret would be all zeroes, the handshake MUST be aborted (most probably by sending a fatal alert). </ins> Let's define legitimate values of x as the values that can be  <ins> obtained as x = X25519(G, d') for some d', and call the other values illegitimate.  The definition of the X25519 function shows that legitimate values all share the following property: the high-order bit of the last byte is not set (for X448, any bit can be set). </ins>  <ins> Since there are some implementation of the X25519 function that </ins> impose this restriction on their input and others that don't,  <ins> implementations of X25519 in TLS SHOULD reject public keys when the high-order bit of the last byte is set (in other words, when the </ins> value of the leftmost byte is greater than 0x7F) in order to prevent implementation fingerprinting. Other than this recommended check, implementations do not need to ensure that the public keys they receive are legitimate: this is not  <ins> necessary for security with X25519. </ins> 6. IANA, please update these two registries to refer to this document. IANA is requested to assign four values from the NamedCurve registry  <ins> with names ecdh_x25519(TBD1), ecdh_x448(TBD2), eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this document as reference. </ins> IANA is requested to assign one value from SignatureAlgorithm Registry with name eddsa(TBD5) with this document as reference.


IANA is requested to assign two values from the NamedCurve registry with names eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this document as reference.  IANA has already assigned the value 29 to <del> ecdh_x25519, and the value 30 to ecdh_x448(TBD2). </del>  IANA is requested to assign one value from SignatureAlgorithm Registry with name eddsa(TBD5) with this document as reference.

Should remove the "TBD2" after ecdh_x448.
Looks good to me. Thanks.

IANA is requested to assign two values from the NamedCurve registry with names eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this document as reference.  IANA has already assigned the value 29 to  <ins> ecdh_x25519, and the value 30 to ecdh_x448. </ins> IANA is requested to assign one value from SignatureAlgorithm Registry with name eddsa(TBD5) with this document as reference.


1. <del> Elliptic Curve Cryptography (ECC) has emerged as an attractive public-key cryptosystem, in particular for mobile (i.e., wireless) environments.  Compared to currently prevalent cryptosystems such as RSA, ECC offers equivalent security with smaller key sizes.  This is illustrated in the following table, based on Lenstra_Verheul, which gives approximate comparable key sizes for symmetric- and asymmetric- key cryptosystems based on the best-known algorithms for attacking them. Smaller key sizes result in savings for power, memory, bandwidth, and computational cost that make ECC especially attractive for constrained environments. </del> This document describes additions to TLS to support ECC, applicable to TLS versions 1.0 RFC2246, 1.1 RFC4346, and 1.2 RFC5246.  The use of ECC in TLS 1.3 is defined in I-D.ietf-tls-tls13, and is explicitly

Removed two paragraphs and a table full of motivation about why ECC is great. In 2016 this is no longer needed. ECC is already mainstream.
+1

1.  This document describes additions to TLS to support ECC, applicable to TLS versions 1.0 RFC2246, 1.1 RFC4346, and 1.2 RFC5246.  The use of ECC in TLS 1.3 is defined in I-D.ietf-tls-tls13, and is explicitly


ECPointFormat ECCurveType  For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight values (ECPointFormat and ECCurveType) reserved for Private Use.  The Added TLS 1.2 to references. Moved RFC 4492 authors to acknowledgements. Removed list of required reading for ECC.

if both draft-ietf-tls-iana-registry-updates and this draft add TLS to the registry names then all the registry will have a consistent naming scheme.
Ship it
Shipped
LGTM

ECPointFormat ECCurveType <ins> IANA is requested to prepend "TLS" to the names of the previous three registries. </ins> For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight values (ECPointFormat and ECCurveType) reserved for Private Use.  The Added TLS 1.2 to references. Moved RFC 4492 authors to acknowledgements. Removed list of required reading for ECC. <ins> Prepended "TLS" to the names of the three registries defined in the IANA Considerations section. </ins>


Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier <del> draft-ietf-tls-rfc4492bis-14 </del>  Abstract out of scope for this document.  In particular, this document defines: <del> the use of the Elliptic Curve Diffie-Hellman key agreement scheme with ephemeral keys to establish the TLS premaster secret, and the use of ECDSA certificates for authentication of TLS peers. </del>  The remainder of this document is organized as follows. ecdh provides an overview of ECC-based key exchange algorithms for TLS. clientauth

Use initialism consistently in the Introduction Mention EdDSA in addition to ECDSA as a signature scheme
lgtm

Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier  <ins> draft-ietf-tls-rfc4492bis-15 </ins> Abstract out of scope for this document.  In particular, this document defines:  <ins> the use of the ECDHE key agreement scheme with ephemeral keys to establish the TLS premaster secret, and the use of ECDSA and EdDSA signatures for authentication of TLS peers. </ins> The remainder of this document is organized as follows. ecdh provides an overview of ECC-based key exchange algorithms for TLS. clientauth


All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional hashing. <del> The default hash function is SHA-1 FIPS.180-2, and sha_size (see ske and cert_verify) is 20.  However, an alternative hash function, such as one of the new SHA hash functions specified in FIPS 180-2 FIPS.180-2, SHOULD be used instead. </del>  All EdDSA computations MUST be performed according to RFC8032 or its succesors.  Data to be signed/verified is run through the EdDSA

RFC 4492 called SHA-1 the "default" hash for ECDSA, because that was the only hash defined in X9.62 at the time. The new X9.62 (new being a relative term - it's from 2005) defines all the SHA-2 hashes as well. We now make the use of secure hashes a MUST and we call out SHA-256, SHA-384, and SHA-512 explicitly as examples. Also had to update the reference to the SHA document from NIST 180-2 (which did not contain SHA-2) to the current NIST 180-4 (which does)

All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional hashing.  <ins> A secure hash function such as SHA-256, SHA-384, or SHA-512 from FIPS.180-4 MUST be used. </ins> All EdDSA computations MUST be performed according to RFC8032 or its succesors.  Data to be signed/verified is run through the EdDSA


ANSI X9.62 ANSI.X9-62.2005 and FIPS 186-4 FIPS.186-4.  The rest of this document refers to these three curves as the "NIST curves" because they were originally standardized by the National Institute <del> of Standards and Technology.  The curves ecdh_x25519 and ecdh_x448 are defined in RFC7748.  Values 0xFE00 through 0xFEFF are reserved for private use. </del>  The predecessor of this document also supported explicitly defined prime and char2 curves, but these are deprecated by this mechanism.) ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte string ECPoint.point, which may represent an elliptic curve point <del> in uncompressed or compressed format.  Curves eddsa_ed25519 and eddsa_ed448 MUST NOT be used here.  Here, the format MUST conform to what the server has requested through a Supported Point Formats Extension if this extension was used, and MUST be uncompressed if this extension was not used. </del>  Actions of the sender: domain parameters recommended in ANSI X9.62, FIPS 186-4, and SEC 2 SECG-SEC2 or in RFC8032. <del> EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the eddsa_ed25519 curve, and Ed448 and Ed448ph keys MUST use the eddsa_ed448 curve.  Curves ecdh_x25519, ecdh_x448, eddsa_ed25519 and eddsa_ed448 MUST NOT be used for ECDSA. </del>  5.10. future TLS versions or new TLS extensions introduced in the future may vary this computation.) <del> An ECDHE key exchange using X25519 (curve ecdh_x25519) goes as follows: Each party picks a secret key d uniformly at random and computes the corresponding public key x = X25519(d, G).  Parties exchange their public keys, and compute a shared secret as x_S = X25519(d, x_peer).  If either party obtains all-zeroes x_S, it MUST abort the handshake (as required by definition of X25519 and X448). ECDHE for X448 works similarily, replacing X25519 with X448, and ecdh_x25519 with ecdh_x448.  The derived shared secret is used directly as the premaster secret, which is always exactly 32 bytes when ECDHE with X25519 is used and 56 bytes when ECDHE with X448 is used. </del>  All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result IANA, please update these two registries to refer to this document. <del> IANA has already assigned the value 29 to ecdh_x25519, and the value 30 to ecdh_x448. </del>  IANA is requested to assign two values from the TLS SignatureAlgorithm Registry with names ed25519(TBD3) and ed448(TBD4)

ecdhx25519 and ecdhx448 no longer have an ecdh_ prefix (.Remove some remnants of EdDSA curves as NamedCurves.TLS 1.3 only uses the PureEdDSA algorithms. If we were to use Ed25519ph, we would want separate SignatureAlgorithm values so the receivers can indicate support.
(NAME suggested I file this here.) In TLS 1.3, we dropped the "ecdh" prefix on ecdhx25519 and ecdh_x448 when we split signatures from NamedCurve/Group. The documents should probably match in naming one way or another. I think plain x25519 and x448 is tidier. X25519 already denotes the ECDH function, as opposed to curve25519 which is the curve.
Looks fine to me

ANSI X9.62 ANSI.X9-62.2005 and FIPS 186-4 FIPS.186-4.  The rest of this document refers to these three curves as the "NIST curves" because they were originally standardized by the National Institute  <ins> of Standards and Technology.  The curves x25519 and x448 are defined in RFC7748.  Values 0xFE00 through 0xFEFF are reserved for private use. </ins> The predecessor of this document also supported explicitly defined prime and char2 curves, but these are deprecated by this mechanism.) ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte string ECPoint.point, which may represent an elliptic curve point  <ins> in uncompressed or compressed format.  Here, the format MUST conform to what the server has requested through a Supported Point Formats Extension if this extension was used, and MUST be uncompressed if this extension was not used. </ins> Actions of the sender: domain parameters recommended in ANSI X9.62, FIPS 186-4, and SEC 2 SECG-SEC2 or in RFC8032.  <ins> EdDSA keys using the Ed25519 algorithm MUST use the ed25519 signature algorithm, and Ed448 keys MUST use the ed448 signature algorithm. This document does not define use of Ed25519ph and Ed448ph keys with TLS.  Ed25519, Ed25519ph, Ed448, and Ed448ph keys MUST NOT be used with ECDSA. </ins> 5.10. future TLS versions or new TLS extensions introduced in the future may vary this computation.)  <ins> An ECDHE key exchange using X25519 (curve x25519) goes as follows: Each party picks a secret key d uniformly at random and computes the corresponding public key x = X25519(d, G).  Parties exchange their public keys, and compute a shared secret as x_S = X25519(d, x_peer). If either party obtains all-zeroes x_S, it MUST abort the handshake (as required by definition of X25519 and X448).  ECDHE for X448 works similarily, replacing X25519 with X448, and x25519 with x448.  The derived shared secret is used directly as the premaster secret, which is always exactly 32 bytes when ECDHE with X25519 is used and 56 bytes when ECDHE with X448 is used. </ins> All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result IANA, please update these two registries to refer to this document.  <ins> IANA is requested to assigned the value 29 to x25519, and the value 30 to x448 in the TLS Supported Groups Registry.  This replaces the temporary registrations ecdh_x25519(29) and ecdh_x448(30). </ins> IANA is requested to assign two values from the TLS SignatureAlgorithm Registry with names ed25519(TBD3) and ed448(TBD4)


point that they may recover the entire private key in a few requests, if that key is not really ephemeral. <del> X25519 was designed in a way that the result of X25519(x, d) will never reveal information about d, provided it was chosen as prescribed, for any value of x (the same holds true for X448). All-zeroes output from X25519 or X448 MUST NOT be used for premaster secret (as required by definition of X25519 and X448).  If the premaster secret would be all zeroes, the handshake MUST be aborted (most probably by sending a fatal alert). Let's define legitimate values of x as the values that can be obtained as x = X25519(G, d') for some d', and call the other values illegitimate.  The definition of the X25519 function shows that legitimate values all share the following property: the high-order bit of the last byte is not set (for X448, any bit can be set). Since there are some implementation of the X25519 function that impose this restriction on their input and others that don't, implementations of X25519 in TLS SHOULD reject public keys when the high-order bit of the final byte is set (in other words, when the value of the rightmost byte is greater than 0x7F) in order to prevent implementation fingerprinting.  Note that this deviates from RFC 7748 which suggests that This value be masked. </del>  Ed25519 and Ed448 internally do public key validation as part of signature verification. <del> Other than this recommended check, implementations do not need to ensure that the public keys they receive are legitimate: this is not necessary for security with X25519. </del> 6. The table below defines new ECC cipher suites that use the key

RFC 7748, TLS 1.3, and existing implementations do not check the significant bit. Instead, they mask it off. Align with all of these. Also tweak the all-zeros citation. RFC 7748 describes it as an optional check.
This looks goo to me.
LGTM

point that they may recover the entire private key in a few requests, if that key is not really ephemeral.  <ins> With X25519 and X448, a receiving party MUST check whether the computed premaster secret is the all-zero value and abort the handshake if so, as described in section 6 of RFC7748. </ins> Ed25519 and Ed448 internally do public key validation as part of signature verification.  6. The table below defines new ECC cipher suites that use the key


encryption/MAC keys and initialization vectors is independent of the key exchange algorithm and not impacted by the introduction of ECC. <del> The table below summarizes the new key exchange algorithms, which mimic DHE_DSS, DHE_RSA, and DH_anon, respectively. The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward secrecy.  With ECDHE_RSA, a server can reuse its existing RSA certificate and easily comply with a constrained client's elliptic curve p references (see tlsext).  However, the computational cost incurred by a server is higher for ECDHE_RSA than for the traditional RSA key exchange, which does not provide forward secrecy. </del>  The anonymous key exchange algorithm does not provide authentication of the server or the client.  Like other anonymous TLS key exchanges,

I've restructured a little in support of this. I think that forward secrecy is more pertinent than the analogous finite-field stuff. I can make this less intrusive if you feel like the changes are gratuitous.

encryption/MAC keys and initialization vectors is independent of the key exchange algorithm and not impacted by the introduction of ECC.  <ins> tbl2 summarizes the new key exchange algorithms.  All of these key exchange algorithms provide forward secrecy. These key exchanges are analogous to DHE_DSS, DHE_RSA, and DH_anon, respectively. With ECDHE_RSA, a server can reuse its existing RSA certificate and easily comply with a constrained client's elliptic curve preferences (see tlsext).  However, the computational cost incurred by a server is higher for ECDHE_RSA than for the traditional RSA key exchange, which does not provide forward secrecy. </ins> The anonymous key exchange algorithm does not provide authentication of the server or the client.  Like other anonymous TLS key exchanges,


Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier <del> draft-ietf-tls-rfc4492bis-03 </del>  Abstract 1. <del> Elliptic Curve Cryptography (ECC) is emerging as an attractive </del>  public-key cryptosystem, in particular for mobile (i.e., wireless) environments.  Compared to currently prevalent cryptosystems such as RSA, ECC offers equivalent security with smaller key sizes.  This is 2.3.  In ECDH_anon, the server's Certificate, the CertificateRequest, the client's Certificate, and the CertificateVerify messages MUST NOT be sent. supported by the client (cf. server_cert and ske). NOTE: A server participating in an ECDHE-ECDSA key exchange may use <del> different curves for (i) the ECDSA key in its certificate, and (ii) the ephemeral ECDH key in the ServerKeyExchange message.  The server must consider the extensions in both cases. </del>  If a server does not understand the Supported Elliptic Curves Extension, does not understand the Supported Point Formats Extension, use in TLS.  Only three have seen any use.  This specification is deprecating the rest (with numbers 1-22).  This specification also deprecates the explicit curves with identifiers 0xFF01 and 0xFF02. <del> This leaves only the following: </del>  Note that other specification have since added other values to this enumeration. secp256r1, etc: Indicates support of the corresponding named curve or <del> class of explicitly defined curves.  The named curves defined here are those specified in SEC 2 SECG-SEC2.  Note that many of these </del>  curves are also recommended in ANSI X9.62 ANSI.X9-62.2005 and FIPS <del> 186-4 FIPS.186-4.  Values 0xFE00 through 0xFEFF are reserved for private use. </del>  The NamedCurve name space is maintained by IANA.  See iana for information on how new value assignments are added. (and the corresponding elliptic curve domain parameters) to the client.  Structure of this message: <del> Indicates the elliptic curve domain parameters are conveyed verbosely, and the underlying finite field is a prime field. Indicates the elliptic curve domain parameters are conveyed verbosely, and the underlying finite field is a characteristic-2 field. Indicates that a named curve is used.  This option SHOULD be used when applicable. </del>  Values 248 through 255 are reserved for private use. The ECCurveType name space is maintained by IANA.  See iana for information on how new value assignments are added. <del> These parameters specify the coefficients of the elliptic curve. Each value contains the byte string representation of a field element following the conversion routine in Section 4.3.3 of ANSI.X9-62.2005. This is the byte string representation of an elliptic curve point following the conversion routine in Section 4.3.6 of ANSI.X9-62.2005.  This byte string may represent an elliptic curve point in uncompressed or compressed format; it MUST conform to what the client has requested through a Supported Point Formats Extension if this extension was used. Indicates representation of a characteristic-2 field using a trinomial basis. Indicates representation of a characteristic-2 field using a pentanomial basis. This identifies the type of the elliptic curve domain parameters. This is the odd prime defining the field Fp. Specifies the coefficients a and b of the elliptic curve E. Specifies the base point G on the elliptic curve. Specifies the order n of the base point. Specifies the cofactor h = #E(Fq)/n, where #E(Fq) represents the number of points on the elliptic curve E defined over the field Fq (either Fp or F2^m). This is the degree of the characteristic-2 field F2^m. The exponent k for the trinomial basis representation x^m + x^k+1. The exponents for the pentanomial representation x^m + x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1). Specifies a recommended set of elliptic curve domain parameters. All those values of NamedCurve are allowed that refer to a specific curve.  Values of NamedCurve that indicate support for a class of explicitly defined curves are not allowed here (they are only permissible in the ClientHello extension); this applies to arbitrary_explicit_prime_curves(0xFF01) and arbitrary_explicit_char2_curves(0xFF02). Specifies the elliptic curve domain parameters associated with the ECDH public key. The ephemeral ECDH public key. </del>  The ServerKeyExchange message is extended as follows. 5.10. <del> All ECDH calculations (including parameter and key generation as well as the shared secret calculation) are performed according to IEEE.P1363.1998 using the ECKAS-DH1 scheme with the identity map as key derivation function (KDF), so that the premaster secret is the x-coordinate of the ECDH shared secret elliptic curve point represented as an octet string.  Note that this octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the Field Element to Octet String Conversion Primitive, has constant length for any given field; leading zeros found in this octet string MUST NOT be truncated. </del>  (Note that this use of the identity KDF is a technicality.  The complete picture is that ECDH is employed with a non-trivial KDF future TLS versions or new TLS extensions introduced in the future may vary this computation.)  All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional hashing. All RSA signatures must be generated and verified according to PKCS1 block type 1.  6. The table below defines new ECC cipher suites that use the key For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight values (ECPointFormat and ECCurveType) reserved for Private Use.  Any <del> additional assignments require IETF Consensus action. </del>  9.

Added new curves and new authors. Partial merge of draft-ietf-tls-curve25519

Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier  <ins> draft-ietf-tls-rfc4492bis-04 </ins> Abstract 1.  <ins> Elliptic Curve Cryptography (ECC) has emerged as an attractive </ins> public-key cryptosystem, in particular for mobile (i.e., wireless) environments.  Compared to currently prevalent cryptosystems such as RSA, ECC offers equivalent security with smaller key sizes.  This is 2.3. <ins> NOTE: Despite the name beginning with "ECDH_" (no E), the key used in ECDH_anon is ephemeral just like the key in ECDHE_RSA and ECDHE_ECDSA.  The naming follows the example of DH_anon, where the key is also ephemeral but the name does not reflect it.  TBD: Do we want to rename this so that it makes sense? </ins> In ECDH_anon, the server's Certificate, the CertificateRequest, the client's Certificate, and the CertificateVerify messages MUST NOT be sent. supported by the client (cf. server_cert and ske). NOTE: A server participating in an ECDHE-ECDSA key exchange may use  <ins> different curves for the ECDSA key in its certificate, and for the ephemeral ECDH key in the ServerKeyExchange message.  The server MUST consider the extensions in both cases. </ins> If a server does not understand the Supported Elliptic Curves Extension, does not understand the Supported Point Formats Extension, use in TLS.  Only three have seen any use.  This specification is deprecating the rest (with numbers 1-22).  This specification also deprecates the explicit curves with identifiers 0xFF01 and 0xFF02.  <ins> It also adds the new curves defined in CFRG-Curves.  The end result is as follows: </ins> Note that other specification have since added other values to this enumeration. secp256r1, etc: Indicates support of the corresponding named curve or  <ins> class of explicitly defined curves.  The named curves secp256r1, secp384r1, and secp521r1 are specified in SEC 2 SECG-SEC2.  These </ins> curves are also recommended in ANSI X9.62 ANSI.X9-62.2005 and FIPS  <ins> 186-4 FIPS.186-4.  Curve25519 and Curve448 are defined in CFRG- Curves.  Values 0xFE00 through 0xFEFF are reserved for private use. </ins> The NamedCurve name space is maintained by IANA.  See iana for information on how new value assignments are added. (and the corresponding elliptic curve domain parameters) to the client. <ins> The ECCCurveType enum used to have values for explicit prime and for explicit char2 curves.  Those values are now deprecated, so only one value remains: </ins> Structure of this message:  <ins> The value named_curve indicates that a named curve is used.  This option SHOULD be used when applicable. </ins> Values 248 through 255 are reserved for private use. The ECCurveType name space is maintained by IANA.  See iana for information on how new value assignments are added.  <ins> RFC 4492 had a specification for an ECCurve structure and an ECBasisType structure.  Both of these are omitted now because they were only used with the now deprecated explicit curves. This is the byte string representation of an elliptic curve point following the conversion routine in Section 4.3.6 of ANSI.X9-62.2005. This byte string may represent an elliptic curve point in uncompressed or compressed format; it MUST conform to what the client has requested through a Supported Point Formats Extension if this extension was used.  For the Curve25519 and Curve448 curves, the only valid representation is the one specified in CFRG-Curves - a 32- or 56-octet representation of the u value of the point. This identifies the type of the elliptic curve domain parameters. Specifies a recommended set of elliptic curve domain parameters.  All those values of NamedCurve are allowed that refer to a specific curve.  Values of NamedCurve that indicate support for a class of explicitly defined curves are not allowed here (they are only permissible in the ClientHello extension); this applies to arbitrary_explicit_prime_curves(0xFF01) and arbitrary_explicit_char2_curves(0xFF02). Specifies the elliptic curve domain parameters associated with the ECDH public key. The ephemeral ECDH public key. </ins> The ServerKeyExchange message is extended as follows. 5.10.  <ins> All ECDH calculations for the NIST curves (including parameter and key generation as well as the shared secret calculation) are performed according to IEEE.P1363.1998 using the ECKAS-DH1 scheme with the identity map as key derivation function (KDF), so that the premaster secret is the x-coordinate of the ECDH shared secret elliptic curve point represented as an octet string.  Note that this octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the Field Element to Octet String Conversion Primitive, has constant length for any given field; leading zeros found in this octet string MUST NOT be truncated. </ins> (Note that this use of the identity KDF is a technicality.  The complete picture is that ECDH is employed with a non-trivial KDF future TLS versions or new TLS extensions introduced in the future may vary this computation.) <ins> An ECDHE key exchange using Curve25519 goes as follows.  Each party picks a secret key d uniformly at random and computes the corresponding public key x = Curve25519(d, G).  Parties exchange their public keys and compute a shared secret as x_S = Curve25519(d, x_peer).  ECDHE for Curve448 works similarily, replacing Curve25519 with Curve448.  The derived shared secret is used directly as the premaster secret, which is always exactly 32 bytes when ECDHE with Curve25519 is used and 56 bytes when ECDHE with Curve448 is used. </ins> All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional hashing. All RSA signatures must be generated and verified according to PKCS1 block type 1. <ins> 5.11. With the NIST curves, each party must validate the public key sent by its peer before performing cryptographic computations with it. Failing to do so allows attackers to gain information about the private key, to the point that they may recover the entire private key in a few requests, if that key is not really ephemeral. Curve25519 was designed in a way that the result of Curve25519(x, d) will never reveal information about d, provided it was chosen as prescribed, for any value of x. Let's define legitimate values of x as the values that can be obtained as x = Curve25519(G, d') for some d, and call the other values illegitimate.  The definition of the Curve25519 function shows that legitimate values all share the following property: the high- order bit of the last byte is not set. Since there are some implementation of the Curve25519 function that impose this restriction on their input and others that don't, implementations of Curve25519 in TLS SHOULD reject public keys when the high-order bit of the last byte is set (in other words, when the value of the leftmost byte is greater than 0x7F) in order to prevent implementation fingerprinting. Other than this recommended check, implementations do not need to ensure that the public keys they receive are legitimate: this is not necessary for security with Curve25519. </ins> 6. The table below defines new ECC cipher suites that use the key For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight values (ECPointFormat and ECCurveType) reserved for Private Use.  Any  <ins> additional assignments require IETF Review. NOTE: IANA, please update the registries to reflect the new policy name. NOTE: RFC editor please delete these two notes prior to publication. IANA, please update these two registries to refer to this document. IANA is requested to assign two values from the NamedCurve registry with names Curve25519(TBD1) and Curve448(TBD2) with this document as reference. </ins> 9.


media stream is considered to be Running, and the state of ICE overall is Running. <del> Once roles are determined for a session, they persist unless ICE is restarted.  An ICE restart causes a new selection of roles and tie- breakers. </del>  5.1.3. The agent MUST include the ICE-CONTROLLED attribute in the request if it is in the controlled role, and MUST include the ICE-CONTROLLING <del> attribute in the request if it is in the controlling role.  The content of either attribute MUST be the tie-breaker that was determined in sec-role.  These attributes are defined fully in sec- </del>  ice-newatts. 6.1.2.4. 6.1.3.1. If the STUN transaction generates a 487 (Role Conflict) error <del> response, the agent checks whether it included the ICE-CONTROLLED or ICE-CONTROLLING attribute in the Binding request.  If the request contained the ICE-CONTROLLED attribute, the agent MUST switch to the controlling role if it has not already done so.  If the request contained the ICE-CONTROLLING attribute, the agent MUST switch to the controlled role if it has not already done so.  Once it has switched, the agent MUST enqueue the candidate pair whose check generated the 487 into the triggered check queue.  The state of that pair is set to Waiting.  When the triggered check is sent, it will contain an ICE- CONTROLLING or ICE-CONTROLLED attribute reflecting its new role. Note, however, that the tie-breaker value MUST NOT be reselected. </del>  A change in roles will require an agent to recompute pair priorities (sec-comp-pair-prio), since those priorities are a function of If the agent is in the controlling role, and the ICE-CONTROLLING attribute is present in the request: <del> If the agent's tie-breaker is larger than or equal to the </del>  contents of the ICE-CONTROLLING attribute, the agent generates a Binding error response and includes an ERROR-CODE attribute with a value of 487 (Role Conflict) but retains its role. <del> If the agent's tie-breaker is less than the contents of the ICE-CONTROLLING attribute, the agent switches to the controlled role. </del>  If the agent is in the controlled role, and the ICE-CONTROLLED attribute is present in the request: <del> If the agent's tie-breaker is larger than or equal to the </del>  contents of the ICE-CONTROLLED attribute, the agent switches to the controlling role. <del> If the agent's tie-breaker is less than the contents of the ICE-CONTROLLED attribute, the agent generates a Binding error response and includes an ERROR-CODE attribute with a value of 487 (Role Conflict) but retains its role. </del>  If the agent is in the controlled role and the ICE-CONTROLLING attribute was present in the request, or the agent was in the 8. An agent MAY restart ICE processing for an existing media stream.  An <del> ICE restart, as the name implies, will cause all previous states of ICE processing to be flushed and checks to start anew.  The only difference between an ICE restart and a brand new media session is that, during the restart, media can continue to be sent to the previously validated pair. </del>  An agent MUST restart ICE for a media stream if: candidates for that stream and MAY include a totally new set of candidates.  9. This section defines a new ICE option, 'ice2'.  The ICE option All endpoints MUST send keepalives for each media session.  These keepalives serve the purpose of keeping NAT bindings alive for the <del> media session.  The keepalives SHOULD be sent using a format that is supported by its peer.  ICE endpoints allow for STUN-based keepalives for UDP streams, and as such, STUN keepalives MUST be used when an agent is a full ICE implementation and is communicating with a peer that supports ICE (lite or full). </del>  If there has been no packet sent on the candidate pair ICE is using for a media component for Tr seconds (where packets include those defined for the component (RTP or RTCP) and previous keepalives), an <del> agent MUST generate a keepalive on that pair.  ICE endpoints SHOULD use a Tr value of 15 seconds, but MAY use another value, e.g. based on configuration or network/NAT characteristics.  For example, if an agent has a dynamic way to discover the binding lifetimes of the intervening NATs, it can use that value to determine Tr. Administrators deploying ICE in more controlled networking environments SHOULD set Tr to the longest duration possible in their environment.  ICE endpoints MUST NOT use a Tr value smaller than 15 seconds. When STUN is being used for keepalives, a STUN Binding Indication is </del>  used RFC5389.  The Indication MUST NOT utilize any authentication mechanism.  It SHOULD contain the FINGERPRINT attribute to aid in demultiplexing, but SHOULD NOT contain any other attributes.  It is 13.  13.1. <del> 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 </del>  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 13.2. <del> 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. </del>  <del> 13.3. </del>  <del> During the ICE gathering phase, ICE agents SHOULD calculate the RTO value using the following formula: </del>  <del> For connectivity checks, ICE agents SHOULD calculate the RTO value using the following formula: </del>  <del> 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. </del>  14. The ICE-CONTROLLED attribute is present in a Binding request and indicates that the client believes it is currently in the controlled role.  The content of the attribute is a 64-bit unsigned integer in <del> network byte order, which contains a random number used for tie- breaking of role conflicts. </del>  The ICE-CONTROLLING attribute is present in a Binding request and indicates that the client believes it is currently in the controlling role.  The content of the attribute is a 64-bit unsigned integer in <del> network byte order, which contains a random number used for tie- breaking of role conflicts. </del>  16.2. This specification defines a single error response code: The Binding request contained either the ICE-CONTROLLING or ICE- <del> CONTROLLED attribute, indicating a role that conflicted with the server.  The server ran a tie-breaker based on the tie-breaker value in the request and determined that the client needs to </del>  switch roles. 17.

Trying to avoid conflicts with txt files by creating a new pull request for the tie-breaker and role changes.

media stream is considered to be Running, and the state of ICE overall is Running.  <ins> Once the roles are determined for a session, they persist througout the lifetime of the session.  The roles can be re-determined as part of an ICE restart (sec-restart), but an ICE agent MUST NOT re- determine the role as part of an ICE restart unless one or more of the following criteria is fulfilled: If the controlling agent is full, and switches to lite, the roles MUST be re-determined if the peer agent is also full. If the ICE restart causes a role conflict, the roles might be re- determined due to the role conflict procedures in sec-role- conflict. NOTE: There are certain 3PCC scenarios where an ICE restart might cause a role conflict. NOTE: The ICE agents needs to inform each other whether they are full or lite before the roles are determined.  The mechanism for that is signalling protocol specific, and outside the scope of the document. An ICE agent MUST be prepared that the peer might re-determine the roles as part of any ICE restart, even if the criteria for doing so are not fulfilled.  This can happen if the peer is compliant with an older version of this specification. </ins> 5.1.3. The agent MUST include the ICE-CONTROLLED attribute in the request if it is in the controlled role, and MUST include the ICE-CONTROLLING  <ins> attribute in the request if it is in the controlling role. The content of either attribute are used as tie-breaker values when an ICE role conflict occurs sec-role-conflict. The ICE-CONTROLLED and ICE-CONTROLLING attributes are defined in sec- </ins> ice-newatts. 6.1.2.4. 6.1.3.1. If the STUN transaction generates a 487 (Role Conflict) error  <ins> response, the agent checks whether it included an ICE-CONTROLLED or ICE-CONTROLLING attribute in the associated Binding request.  If the request contained an ICE-CONTROLLED attribute, the agent MUST switch to the controlling role.  If the request contained an ICE-CONTROLLING attribute, the agent MUST switch to the controlled role. Once the agent has switched its role, the agent MUST enqueue the candidate pair whose check generated the 487 into the triggered check queue.  The state of that pair is set to Waiting.  When the triggered check is sent, it will contain an ICE-CONTROLLING or ICE-CONTROLLED attribute reflecting its new role.  The agent MUST NOT change the tie-breaker value. </ins> A change in roles will require an agent to recompute pair priorities (sec-comp-pair-prio), since those priorities are a function of If the agent is in the controlling role, and the ICE-CONTROLLING attribute is present in the request:  <ins> If the agent's tie-breaker value is larger than or equal to the </ins> contents of the ICE-CONTROLLING attribute, the agent generates a Binding error response and includes an ERROR-CODE attribute with a value of 487 (Role Conflict) but retains its role.  <ins> If the agent's tie-breaker value is less than the contents of the ICE-CONTROLLING attribute, the agent switches to the controlled role. </ins> If the agent is in the controlled role, and the ICE-CONTROLLED attribute is present in the request:  <ins> If the agent's tie-breaker value is larger than or equal to the </ins> contents of the ICE-CONTROLLED attribute, the agent switches to the controlling role.  <ins> If the agent's tie-breaker value is less than the contents of the ICE-CONTROLLED attribute, the agent generates a Binding error response and includes an ERROR-CODE attribute with a value of 487 (Role Conflict) but retains its role. </ins> If the agent is in the controlled role and the ICE-CONTROLLING attribute was present in the request, or the agent was in the 8. An agent MAY restart ICE processing for an existing media stream.  An  <ins> ICE restart will cause all previous states, excluding the roles of the agents, of ICE processing to be flushed and checks to start anew. The only difference between an ICE restart and a brand new media session is that during the restart media can continue to be sent to the previously validated pair, and that a new media session always requires the roles to be determined. </ins> An agent MUST restart ICE for a media stream if: candidates for that stream and MAY include a totally new set of candidates. <ins> As described in sec-role, ICE agents MUST NOT re-determine the roles as part as an ICE restart, unless certain criteria that require the roles to be re-determined is fulfilled. </ins> 9. This section defines a new ICE option, 'ice2'.  The ICE option All endpoints MUST send keepalives for each media session.  These keepalives serve the purpose of keeping NAT bindings alive for the  <ins> media session.  These keepalives MUST be sent even if ICE is not being utilized for the session at all.  The keepalive SHOULD be sent using a format that is supported by its peer.  ICE endpoints allow for STUN-based keepalives for UDP streams, and as such, STUN keepalives MUST be used when an agent is a full ICE implementation and is communicating with a peer that supports ICE (lite or full). If the peer does not support ICE, the choice of a packet format for keepalives is a matter of local implementation.  A format that allows packets to easily be sent in the absence of actual media content is RECOMMENDED.  Examples of formats that readily meet this goal are RTP No-Op I-D.ietf-avt-rtp-no-op, and in cases where both sides support it, RTP comfort noise RFC3389.  If the peer doesn't support any formats that are particularly well suited for keepalives, an agent SHOULD send RTP packets with an incorrect version number, or some other form of error that would cause them to be discarded by the peer. </ins> If there has been no packet sent on the candidate pair ICE is using for a media component for Tr seconds (where packets include those defined for the component (RTP or RTCP) and previous keepalives), an  <ins> agent MUST generate a keepalive on that pair.  Tr SHOULD be configurable and SHOULD have a default of 15 seconds.  Tr MUST NOT be configured to less than 15 seconds.  Alternatively, if an agent has a dynamic way to discover the binding lifetimes of the intervening NATs, it can use that value to determine Tr.  Administrators deploying ICE in more controlled networking environments SHOULD set Tr to the longest duration possible in their environment. If STUN is being used for keepalives, a STUN Binding Indication is </ins> used RFC5389.  The Indication MUST NOT utilize any authentication mechanism.  It SHOULD contain the FINGERPRINT attribute to aid in demultiplexing, but SHOULD NOT contain any other attributes.  It is 13. <ins> 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. </ins> 13.1.  <ins> 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 </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 13.2.  <ins> 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. </ins>  <ins> 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. </ins>  <ins> In addition, the retransmission timer for the STUN transactions, RTO, SHOULD be configurable and during the gathering phase, SHOULD have a default of: </ins>  <ins> where the number of pairs refers to the number of pairs of candidates with STUN or TURN servers. </ins>  <ins> For connectivity checks, RTO SHOULD be configurable and SHOULD have a default of: </ins> 14. The ICE-CONTROLLED attribute is present in a Binding request and indicates that the client believes it is currently in the controlled role.  The content of the attribute is a 64-bit unsigned integer in  <ins> network byte order, which contains a random number.  The number is used for solving role conflicts, when it is referred to as the tie- breaker value.  An ICE agent MUST use the same number for all Binding requests, for all streams, within an ICE session.  The ICE agent MAY change the number when an ICE restart occurs. </ins> The ICE-CONTROLLING attribute is present in a Binding request and indicates that the client believes it is currently in the controlling role.  The content of the attribute is a 64-bit unsigned integer in  <ins> network byte order, which contains a random number.  The number is used for solving role conflicts, when it is referred to as the tie- breaker value.  An ICE agent MUST use the same number for all Binding requests, for all streams, within an ICE session.  The ICE agent MAY change the number when an ICE restart occurs. </ins> 16.2. This specification defines a single error response code: The Binding request contained either the ICE-CONTROLLING or ICE-  <ins> CONTROLLED attribute, indicating an ICE role that conflicted with the server.  The server compared the tie-breaker values of the client and the server and determined that the client needs to </ins> switch roles. 17.


ICE agents SHOULD use the default Ta value, 50 ms, but MAY use another value based on the characteristics of the associated media. <del> ICE agents MUST NOT use a Ta value smaller than 5 ms. </del> 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 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.

Annex B.1 also contain some text regarding the rate. E.g. "The definition of a "reasonable" rate is that STUN should not use more bandwidth than the RTP itself will use, once media starts flowing." I guess we should discuss whether: 1) We need to remove/modify that text 2) Whether B.1 is the place where we should talk about the global rate limit.
I'll own this issue because I'm driving discussion on the list around the transport guys' proposal for "MaxPackets+HTO+pacing".
Hopefully fixed by URL

ICE agents SHOULD use the default Ta value, 50 ms, but MAY use another value based on the characteristics of the associated media.  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 values.  If an agent does not propose a value, the default value is used for that agent when comparing which value is higher. <ins> Regardless of the Ta value chosen for each ICE agent, the combination of all transactions from all ICE agents (if a given implementation runs several concurrent ICE agents) MUST NOT be sent more often than once every 5ms (as though there were one global Ta value for pacing all ICE agents). This mechanism of a global minimum pacing interval of 5ms is not generally applicable to transport protocols, but is applicable to ICE based on the following reasoning. Start with the following rules which would be generally applicable to transport protocols: Let MaxBytes be the maximum number of bytes allowed to be outstanding in the network at start-up, which SHOULD be 14600 bytes per RFC 6928. Let HTO be the transaction timeout, which SHOULD be 2*RTT if RTT is known and 500ms otherwise.  This is based on the RTO for STUN messages from RFC 5389 and the the TCP initial RTO, which is 1 sec in RFC 6298. Let MinPacing be the minimum pacing interval between transactions, which SHOULD be 5ms. Observe that ICE agents typically do not know the RTT for ICE transactions (connectivity checks in particular), meaning that HTO will almost always be 500ms. Observe that a MinPacing of 5ms and HTO of 500ms gives at most 100 packets/HTO, which for a typical ICE check of less than 120 bytes means a maximum of 12000 outstanding bytes in the network, which is less than the maximum expressed by rule 1. Thus, for ICE, the rule set reduces down to just the MinPacing rule, which is equivalant to having a global Ta value. </ins> NOTE: sec-concheckbw shows examples of required bandwidth, using different Ta values.