Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 8446

The Transport Layer Security (TLS) Protocol Version 1.3

Pages: 160
Proposed Standard
Obsoletes:  507752466961
Updates:  57056066
Part 6 of 8 – Pages 98 to 119
First   Prev   Next

Top   ToC   RFC8446 - Page 98   prevText

8. 0-RTT and Anti-Replay

As noted in Section 2.3 and Appendix E.5, TLS does not provide inherent replay protections for 0-RTT data. There are two potential threats to be concerned with: - Network attackers who mount a replay attack by simply duplicating a flight of 0-RTT data. - Network attackers who take advantage of client retry behavior to arrange for the server to receive multiple copies of an application message. This threat already exists to some extent because clients that value robustness respond to network errors by attempting to retry requests. However, 0-RTT adds an additional dimension for any server system which does not maintain globally consistent server state. Specifically, if a server system has multiple zones where tickets from zone A will not be accepted in zone B, then an attacker can duplicate a ClientHello and early data intended for A to both A and B. At A, the data will be accepted in 0-RTT, but at B the server will reject 0-RTT data and instead force a full handshake. If the attacker blocks the ServerHello from A, then the client will complete the handshake with B and probably retry the request, leading to duplication on the server system as a whole. The first class of attack can be prevented by sharing state to guarantee that the 0-RTT data is accepted at most once. Servers SHOULD provide that level of replay safety by implementing one of the methods described in this section or by equivalent means. It is understood, however, that due to operational concerns not all deployments will maintain state at that level. Therefore, in normal operation, clients will not know which, if any, of these mechanisms servers actually implement and hence MUST only send early data which they deem safe to be replayed. In addition to the direct effects of replays, there is a class of attacks where even operations normally considered idempotent could be exploited by a large number of replays (timing attacks, resource limit exhaustion and others, as described in Appendix E.5). Those can be mitigated by ensuring that every 0-RTT payload can be replayed only a limited number of times. The server MUST ensure that any instance of it (be it a machine, a thread, or any other entity within the relevant serving infrastructure) would accept 0-RTT for the same 0-RTT handshake at most once; this limits the number of replays to the number of server instances in the deployment. Such a guarantee can be accomplished by locally recording data from recently received ClientHellos and rejecting repeats, or by any other method that
Top   ToC   RFC8446 - Page 99
   provides the same or a stronger guarantee.  The "at most once per
   server instance" guarantee is a minimum requirement; servers SHOULD
   limit 0-RTT replays further when feasible.

   The second class of attack cannot be prevented at the TLS layer and
   MUST be dealt with by any application.  Note that any application
   whose clients implement any kind of retry behavior already needs to
   implement some sort of anti-replay defense.

8.1. Single-Use Tickets

The simplest form of anti-replay defense is for the server to only allow each session ticket to be used once. For instance, the server can maintain a database of all outstanding valid tickets, deleting each ticket from the database as it is used. If an unknown ticket is provided, the server would then fall back to a full handshake. If the tickets are not self-contained but rather are database keys, and the corresponding PSKs are deleted upon use, then connections established using PSKs enjoy forward secrecy. This improves security for all 0-RTT data and PSK usage when PSK is used without (EC)DHE. Because this mechanism requires sharing the session database between server nodes in environments with multiple distributed servers, it may be hard to achieve high rates of successful PSK 0-RTT connections when compared to self-encrypted tickets. Unlike session databases, session tickets can successfully do PSK-based session establishment even without consistent storage, though when 0-RTT is allowed they still require consistent storage for anti-replay of 0-RTT data, as detailed in the following section.

8.2. Client Hello Recording

An alternative form of anti-replay is to record a unique value derived from the ClientHello (generally either the random value or the PSK binder) and reject duplicates. Recording all ClientHellos causes state to grow without bound, but a server can instead record ClientHellos within a given time window and use the "obfuscated_ticket_age" to ensure that tickets aren't reused outside that window. In order to implement this, when a ClientHello is received, the server first verifies the PSK binder as described in Section 4.2.11. It then computes the expected_arrival_time as described in the next section and rejects 0-RTT if it is outside the recording window, falling back to the 1-RTT handshake.
Top   ToC   RFC8446 - Page 100
   If the expected_arrival_time is in the window, then the server checks
   to see if it has recorded a matching ClientHello.  If one is found,
   it either aborts the handshake with an "illegal_parameter" alert or
   accepts the PSK but rejects 0-RTT.  If no matching ClientHello is
   found, then it accepts 0-RTT and then stores the ClientHello for as
   long as the expected_arrival_time is inside the window.  Servers MAY
   also implement data stores with false positives, such as Bloom
   filters, in which case they MUST respond to apparent replay by
   rejecting 0-RTT but MUST NOT abort the handshake.

   The server MUST derive the storage key only from validated sections
   of the ClientHello.  If the ClientHello contains multiple PSK
   identities, then an attacker can create multiple ClientHellos with
   different binder values for the less-preferred identity on the
   assumption that the server will not verify it (as recommended by
   Section 4.2.11).  I.e., if the client sends PSKs A and B but the
   server prefers A, then the attacker can change the binder for B
   without affecting the binder for A.  If the binder for B is part of
   the storage key, then this ClientHello will not appear as a
   duplicate, which will cause the ClientHello to be accepted, and may
   cause side effects such as replay cache pollution, although any 0-RTT
   data will not be decryptable because it will use different keys.  If
   the validated binder or the ClientHello.random is used as the storage
   key, then this attack is not possible.

   Because this mechanism does not require storing all outstanding
   tickets, it may be easier to implement in distributed systems with
   high rates of resumption and 0-RTT, at the cost of potentially weaker
   anti-replay defense because of the difficulty of reliably storing and
   retrieving the received ClientHello messages.  In many such systems,
   it is impractical to have globally consistent storage of all the
   received ClientHellos.  In this case, the best anti-replay protection
   is provided by having a single storage zone be authoritative for a
   given ticket and refusing 0-RTT for that ticket in any other zone.
   This approach prevents simple replay by the attacker because only one
   zone will accept 0-RTT data.  A weaker design is to implement
   separate storage for each zone but allow 0-RTT in any zone.  This
   approach limits the number of replays to once per zone.  Application
   message duplication of course remains possible with either design.

   When implementations are freshly started, they SHOULD reject 0-RTT as
   long as any portion of their recording window overlaps the startup
   time.  Otherwise, they run the risk of accepting replays which were
   originally sent during that period.
Top   ToC   RFC8446 - Page 101
   Note: If the client's clock is running much faster than the server's,
   then a ClientHello may be received that is outside the window in the
   future, in which case it might be accepted for 1-RTT, causing a
   client retry, and then acceptable later for 0-RTT.  This is another
   variant of the second form of attack described in Section 8.

8.3. Freshness Checks

Because the ClientHello indicates the time at which the client sent it, it is possible to efficiently determine whether a ClientHello was likely sent reasonably recently and only accept 0-RTT for such a ClientHello, otherwise falling back to a 1-RTT handshake. This is necessary for the ClientHello storage mechanism described in Section 8.2 because otherwise the server needs to store an unlimited number of ClientHellos, and is a useful optimization for self- contained single-use tickets because it allows efficient rejection of ClientHellos which cannot be used for 0-RTT. In order to implement this mechanism, a server needs to store the time that the server generated the session ticket, offset by an estimate of the round-trip time between client and server. I.e., adjusted_creation_time = creation_time + estimated_RTT This value can be encoded in the ticket, thus avoiding the need to keep state for each outstanding ticket. The server can determine the client's view of the age of the ticket by subtracting the ticket's "ticket_age_add" value from the "obfuscated_ticket_age" parameter in the client's "pre_shared_key" extension. The server can determine the expected_arrival_time of the ClientHello as: expected_arrival_time = adjusted_creation_time + clients_ticket_age When a new ClientHello is received, the expected_arrival_time is then compared against the current server wall clock time and if they differ by more than a certain amount, 0-RTT is rejected, though the 1-RTT handshake can be allowed to complete.
Top   ToC   RFC8446 - Page 102
   There are several potential sources of error that might cause
   mismatches between the expected_arrival_time and the measured time.
   Variations in client and server clock rates are likely to be minimal,
   though potentially the absolute times may be off by large values.
   Network propagation delays are the most likely causes of a mismatch
   in legitimate values for elapsed time.  Both the NewSessionTicket and
   ClientHello messages might be retransmitted and therefore delayed,
   which might be hidden by TCP.  For clients on the Internet, this
   implies windows on the order of ten seconds to account for errors in
   clocks and variations in measurements; other deployment scenarios may
   have different needs.  Clock skew distributions are not symmetric, so
   the optimal tradeoff may involve an asymmetric range of permissible
   mismatch values.

   Note that freshness checking alone is not sufficient to prevent
   replays because it does not detect them during the error window,
   which -- depending on bandwidth and system capacity -- could include
   billions of replays in real-world settings.  In addition, this
   freshness checking is only done at the time the ClientHello is
   received and not when subsequent early Application Data records are
   received.  After early data is accepted, records may continue to be
   streamed to the server over a longer time period.

9. Compliance Requirements

9.1. Mandatory-to-Implement Cipher Suites

In the absence of an application profile standard specifying otherwise: A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see Appendix B.4). A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].
Top   ToC   RFC8446 - Page 103

9.2. Mandatory-to-Implement Extensions

In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the following TLS extensions: - Supported Versions ("supported_versions"; Section 4.2.1) - Cookie ("cookie"; Section 4.2.2) - Signature Algorithms ("signature_algorithms"; Section 4.2.3) - Signature Algorithms Certificate ("signature_algorithms_cert"; Section 4.2.3) - Negotiated Groups ("supported_groups"; Section 4.2.7) - Key Share ("key_share"; Section 4.2.8) - Server Name Indication ("server_name"; Section 3 of [RFC6066]) All implementations MUST send and use these extensions when offering applicable features: - "supported_versions" is REQUIRED for all ClientHello, ServerHello, and HelloRetryRequest messages. - "signature_algorithms" is REQUIRED for certificate authentication. - "supported_groups" is REQUIRED for ClientHello messages using DHE or ECDHE key exchange. - "key_share" is REQUIRED for DHE or ECDHE key exchange. - "pre_shared_key" is REQUIRED for PSK key agreement. - "psk_key_exchange_modes" is REQUIRED for PSK key agreement.
Top   ToC   RFC8446 - Page 104
   A client is considered to be attempting to negotiate using this
   specification if the ClientHello contains a "supported_versions"
   extension with 0x0304 contained in its body.  Such a ClientHello
   message MUST meet the following requirements:

   -  If not containing a "pre_shared_key" extension, it MUST contain
      both a "signature_algorithms" extension and a "supported_groups"

   -  If containing a "supported_groups" extension, it MUST also contain
      a "key_share" extension, and vice versa.  An empty
      KeyShare.client_shares vector is permitted.

   Servers receiving a ClientHello which does not conform to these
   requirements MUST abort the handshake with a "missing_extension"

   Additionally, all implementations MUST support the use of the
   "server_name" extension with applications capable of using it.
   Servers MAY require clients to send a valid "server_name" extension.
   Servers requiring this extension SHOULD respond to a ClientHello
   lacking a "server_name" extension by terminating the connection with
   a "missing_extension" alert.

9.3. Protocol Invariants

This section describes invariants that TLS endpoints and middleboxes MUST follow. It also applies to earlier versions of TLS. TLS is designed to be securely and compatibly extensible. Newer clients or servers, when communicating with newer peers, should negotiate the most preferred common parameters. The TLS handshake provides downgrade protection: Middleboxes passing traffic between a newer client and newer server without terminating TLS should be unable to influence the handshake (see Appendix E.1). At the same time, deployments update at different rates, so a newer client or server MAY continue to support older parameters, which would allow it to interoperate with older endpoints.
Top   ToC   RFC8446 - Page 105
   For this to work, implementations MUST correctly handle extensible

   -  A client sending a ClientHello MUST support all parameters
      advertised in it.  Otherwise, the server may fail to interoperate
      by selecting one of those parameters.

   -  A server receiving a ClientHello MUST correctly ignore all
      unrecognized cipher suites, extensions, and other parameters.
      Otherwise, it may fail to interoperate with newer clients.  In
      TLS 1.3, a client receiving a CertificateRequest or
      NewSessionTicket MUST also ignore all unrecognized extensions.

   -  A middlebox which terminates a TLS connection MUST behave as a
      compliant TLS server (to the original client), including having a
      certificate which the client is willing to accept, and also as a
      compliant TLS client (to the original server), including verifying
      the original server's certificate.  In particular, it MUST
      generate its own ClientHello containing only parameters it
      understands, and it MUST generate a fresh ServerHello random
      value, rather than forwarding the endpoint's value.

      Note that TLS's protocol requirements and security analysis only
      apply to the two connections separately.  Safely deploying a TLS
      terminator requires additional security considerations which are
      beyond the scope of this document.

   -  A middlebox which forwards ClientHello parameters it does not
      understand MUST NOT process any messages beyond that ClientHello.
      It MUST forward all subsequent traffic unmodified.  Otherwise, it
      may fail to interoperate with newer clients and servers.

      Forwarded ClientHellos may contain advertisements for features not
      supported by the middlebox, so the response may include future TLS
      additions the middlebox does not recognize.  These additions MAY
      change any message beyond the ClientHello arbitrarily.  In
      particular, the values sent in the ServerHello might change, the
      ServerHello format might change, and the TLSCiphertext format
      might change.

   The design of TLS 1.3 was constrained by widely deployed
   non-compliant TLS middleboxes (see Appendix D.4); however, it does
   not relax the invariants.  Those middleboxes continue to be
Top   ToC   RFC8446 - Page 106

10. Security Considerations

Security issues are discussed throughout this memo, especially in Appendices C, D, and E.

11. IANA Considerations

This document uses several registries that were originally created in [RFC4346] and updated in [RFC8447]. IANA has updated these to reference this document. The registries and their allocation policies are below: - TLS Cipher Suites registry: values with the first byte in the range 0-254 (decimal) are assigned via Specification Required [RFC8126]. Values with the first byte 255 (decimal) are reserved for Private Use [RFC8126]. IANA has added the cipher suites listed in Appendix B.4 to the registry. The "Value" and "Description" columns are taken from the table. The "DTLS-OK" and "Recommended" columns are both marked as "Y" for each new cipher suite. - TLS ContentType registry: Future values are allocated via Standards Action [RFC8126]. - TLS Alerts registry: Future values are allocated via Standards Action [RFC8126]. IANA has populated this registry with the values from Appendix B.2. The "DTLS-OK" column is marked as "Y" for all such values. Values marked as "_RESERVED" have comments describing their previous usage. - TLS HandshakeType registry: Future values are allocated via Standards Action [RFC8126]. IANA has updated this registry to rename item 4 from "NewSessionTicket" to "new_session_ticket" and populated this registry with the values from Appendix B.3. The "DTLS-OK" column is marked as "Y" for all such values. Values marked "_RESERVED" have comments describing their previous or temporary usage.
Top   ToC   RFC8446 - Page 107
   This document also uses the TLS ExtensionType Values registry
   originally created in [RFC4366].  IANA has updated it to reference
   this document.  Changes to the registry follow:

   -  IANA has updated the registration policy as follows:

      Values with the first byte in the range 0-254 (decimal) are
      assigned via Specification Required [RFC8126].  Values with the
      first byte 255 (decimal) are reserved for Private Use [RFC8126].

   -  IANA has updated this registry to include the "key_share",
      "pre_shared_key", "psk_key_exchange_modes", "early_data",
      "cookie", "supported_versions", "certificate_authorities",
      "oid_filters", "post_handshake_auth", and
      "signature_algorithms_cert" extensions with the values defined in
      this document and the "Recommended" value of "Y".

   -  IANA has updated this registry to include a "TLS 1.3" column which
      lists the messages in which the extension may appear.  This column
      has been initially populated from the table in Section 4.2, with
      any extension not listed there marked as "-" to indicate that it
      is not used by TLS 1.3.

   This document updates an entry in the TLS Certificate Types registry
   originally created in [RFC6091] and updated in [RFC8447].  IANA has
   updated the entry for value 1 to have the name "OpenPGP_RESERVED",
   "Recommended" value "N", and comment "Used in TLS versions prior
   to 1.3."

   This document updates an entry in the TLS Certificate Status Types
   registry originally created in [RFC6961].  IANA has updated the entry
   for value 2 to have the name "ocsp_multi_RESERVED" and comment "Used
   in TLS versions prior to 1.3".

   This document updates two entries in the TLS Supported Groups
   registry (created under a different name by [RFC4492]; now maintained
   by [RFC8422]) and updated by [RFC7919] and [RFC8447].  The entries
   for values 29 and 30 (x25519 and x448) have been updated to also
   refer to this document.
Top   ToC   RFC8446 - Page 108
   In addition, this document defines two new registries that are
   maintained by IANA:

   -  TLS SignatureScheme registry: Values with the first byte in the
      range 0-253 (decimal) are assigned via Specification Required
      [RFC8126].  Values with the first byte 254 or 255 (decimal) are
      reserved for Private Use [RFC8126].  Values with the first byte in
      the range 0-6 or with the second byte in the range 0-3 that are
      not currently allocated are reserved for backward compatibility.
      This registry has a "Recommended" column.  The registry has been
      initially populated with the values described in Section 4.2.3.
      The following values are marked as "Recommended":
      ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
      rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512,
      rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and
      ed25519.  The "Recommended" column is assigned a value of "N"
      unless explicitly requested, and adding a value with a
      "Recommended" value of "Y" requires Standards Action [RFC8126].
      IESG Approval is REQUIRED for a Y->N transition.

   -  TLS PskKeyExchangeMode registry: Values in the range 0-253
      (decimal) are assigned via Specification Required [RFC8126].
      The values 254 and 255 (decimal) are reserved for Private Use
      [RFC8126].  This registry has a "Recommended" column.  The
      registry has been initially populated with psk_ke (0) and
      psk_dhe_ke (1).  Both are marked as "Recommended".  The
      "Recommended" column is assigned a value of "N" unless explicitly
      requested, and adding a value with a "Recommended" value of "Y"
      requires Standards Action [RFC8126].  IESG Approval is REQUIRED
      for a Y->N transition.
Top   ToC   RFC8446 - Page 109

12. References

12.1. Normative References

[DH76] Diffie, W. and M. Hellman, "New directions in cryptography", IEEE Transactions on Information Theory, Vol. 22 No. 6, pp. 644-654, DOI 10.1109/TIT.1976.1055638, November 1976. [ECDSA] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI ANS X9.62-2005, November 2005. [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>. [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <>. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <>. [RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <>. [RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010, <>.
Top   ToC   RFC8446 - Page 110
   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,

   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066,
              DOI 10.17487/RFC6066, January 2011,

   [RFC6655]  McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
              Transport Layer Security (TLS)", RFC 6655,
              DOI 10.17487/RFC6655, July 2012,

   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
              Galperin, S., and C. Adams, "X.509 Internet Public Key
              Infrastructure Online Certificate Status Protocol - OCSP",
              RFC 6960, DOI 10.17487/RFC6960, June 2013,

   [RFC6961]  Pettersen, Y., "The Transport Layer Security (TLS)
              Multiple Certificate Status Request Extension", RFC 6961,
              DOI 10.17487/RFC6961, June 2013,

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,

   [RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature
              Algorithm (DSA) and Elliptic Curve Digital Signature
              Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979,
              August 2013, <>.

   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
              July 2014, <>.

   [RFC7507]  Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
              Suite Value (SCSV) for Preventing Protocol Downgrade
              Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748,
              January 2016, <>.
Top   ToC   RFC8446 - Page 111
   [RFC7919]  Gillmor, D., "Negotiated Finite Field Diffie-Hellman
              Ephemeral Parameters for Transport Layer Security (TLS)",
              RFC 7919, DOI 10.17487/RFC7919, August 2016,

   [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
              "PKCS #1: RSA Cryptography Specifications Version 2.2",
              RFC 8017, DOI 10.17487/RFC8017, November 2016,

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              RFC 2119 Key Words", BCP 14, RFC 8174,
              DOI 10.17487/RFC8174, May 2017,

   [RFC8439]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
              Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,

   [SHS]      Dang, Q., "Secure Hash Standard (SHS)", National Institute
              of Standards and Technology report,
              DOI 10.6028/NIST.FIPS.180-4, August 2015.

   [X690]     ITU-T, "Information technology -- ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ISO/IEC 8825-1:2015, November 2015.
Top   ToC   RFC8446 - Page 112

12.2. Informative References

[AEAD-LIMITS] Luykx, A. and K. Paterson, "Limits on Authenticated Encryption Use in TLS", August 2017, <>. [BBFGKZ16] Bhargavan, K., Brzuska, C., Fournet, C., Green, M., Kohlweiss, M., and S. Zanella-Beguelin, "Downgrade Resilience in Key-Exchange Protocols", Proceedings of IEEE Symposium on Security and Privacy (San Jose), DOI 10.1109/SP.2016.37, May 2016. [BBK17] Bhargavan, K., Blanchet, B., and N. Kobeissi, "Verified Models and Reference Implementations for the TLS 1.3 Standard Candidate", Proceedings of IEEE Symposium on Security and Privacy (San Jose), DOI 10.1109/SP.2017.26, May 2017. [BDFKPPRSZZ16] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Kohlweiss, M., Pan, J., Protzenko, J., Rastogi, A., Swamy, N., Zanella-Beguelin, S., and J. Zinzindohoue, "Implementing and Proving the TLS 1.3 Record Layer", Proceedings of IEEE Symposium on Security and Privacy (San Jose), May 2017, <>. [Ben17a] Benjamin, D., "Presentation before the TLS WG at IETF 100", November 2017, < slides-100-tls-sessa-tls13/>. [Ben17b] Benjamin, D., "Additional TLS 1.3 results from Chrome", message to the TLS mailing list, 18 December 2017, < msg25168.html>. [Blei98] Bleichenbacher, D., "Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1", Proceedings of CRYPTO '98, 1998. [BMMRT15] Badertscher, C., Matt, C., Maurer, U., Rogaway, P., and B. Tackmann, "Augmented Secure Channels and the Goal of the TLS 1.3 Record Layer", ProvSec 2015, September 2015, <>.
Top   ToC   RFC8446 - Page 113
   [BT16]     Bellare, M. and B. Tackmann, "The Multi-User Security of
              Authenticated Encryption: AES-GCM in TLS 1.3", Proceedings
              of CRYPTO 2016, July 2016,

   [CCG16]    Cohn-Gordon, K., Cremers, C., and L. Garratt, "On
              Post-compromise Security", IEEE Computer Security
              Foundations Symposium, DOI 10.1109/CSF.2016.19, July 2015.

              Checkoway, S., Maskiewicz, J., Garman, C., Fried, J.,
              Cohney, S., Green, M., Heninger, N., Weinmann, R.,
              Rescorla, E., and H. Shacham, "A Systematic Analysis of
              the Juniper Dual EC Incident", Proceedings of the 2016 ACM
              SIGSAC Conference on Computer and Communications Security
              - CCS '16, DOI 10.1145/2976749.2978395, October 2016.

   [CHHSV17]  Cremers, C., Horvat, M., Hoyland, J., Scott, S., and T.
              van der Merwe, "Awkward Handshake: Possible mismatch of
              client/server view on client authentication in
              post-handshake mode in Revision 18", message to the TLS
              mailing list, 10 February 2017, <

   [CHSV16]   Cremers, C., Horvat, M., Scott, S., and T. van der Merwe,
              "Automated Analysis and Verification of TLS 1.3: 0-RTT,
              Resumption and Delayed Authentication", Proceedings of
              IEEE Symposium on Security and Privacy (San Jose),
              DOI 10.1109/SP.2016.35, May 2016,

   [CK01]     Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange
              Protocols and Their Use for Building Secure Channels",
              Proceedings of Eurocrypt 2001,
              DOI 10.1007/3-540-44987-6_28, April 2001.

   [CLINIC]   Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know
              Why You Went to the Clinic: Risks and Realization of HTTPS
              Traffic Analysis", Privacy Enhancing Technologies, pp.
              143-163, DOI 10.1007/978-3-319-08506-7_8, 2014.

   [DFGS15]   Dowling, B., Fischlin, M., Guenther, F., and D. Stebila,
              "A Cryptographic Analysis of the TLS 1.3 Handshake
              Protocol Candidates", Proceedings of ACM CCS 2015,
              October 2015, <>.
Top   ToC   RFC8446 - Page 114
   [DFGS16]   Dowling, B., Fischlin, M., Guenther, F., and D. Stebila,
              "A Cryptographic Analysis of the TLS 1.3 Full and
              Pre-shared Key Handshake Protocol", TRON 2016,
              February 2016, <>.

   [DOW92]    Diffie, W., van Oorschot, P., and M. Wiener,
              "Authentication and authenticated key exchanges", Designs,
              Codes and Cryptography, DOI 10.1007/BF00124891, June 1992.

   [DSS]      National Institute of Standards and Technology, U.S.
              Department of Commerce, "Digital Signature Standard
              (DSS)", NIST FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4,
              July 2013.

   [FG17]     Fischlin, M. and F. Guenther, "Replay Attacks on Zero
              Round-Trip Time: The Case of the TLS 1.3 Handshake
              Candidates", Proceedings of EuroS&P 2017, April 2017,

   [FGSW16]   Fischlin, M., Guenther, F., Schmidt, B., and B. Warinschi,
              "Key Confirmation in Key Exchange: A Formal Treatment and
              Implications for TLS 1.3", Proceedings of IEEE Symposium
              on Security and Privacy (San Jose),
              DOI 10.1109/SP.2016.34, May 2016,

   [FW15]     Weimer, F., "Factoring RSA Keys With TLS Perfect Forward
              Secrecy", September 2015.

   [HCJC16]   Husak, M., Cermak, M., Jirsik, T., and P. Celeda, "HTTPS
              traffic analysis and client identification using passive
              SSL/TLS fingerprinting", EURASIP Journal on Information
              Security, Vol. 2016, DOI 10.1186/s13635-016-0030-7,
              February 2016.

   [HGFS15]   Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes,
              "Prying Open Pandora's Box: KCI Attacks against TLS",
              Proceedings of USENIX Workshop on Offensive Technologies,
              August 2015.

              IEEE, "IEEE Standard Specifications for Public Key
              Cryptography", IEEE Std. 1363-2000,
              DOI 10.1109/IEEESTD.2000.92292.
Top   ToC   RFC8446 - Page 115
   [JSS15]    Jager, T., Schwenk, J., and J. Somorovsky, "On the
              Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1
              v1.5 Encryption", Proceedings of ACM CCS 2015,
              DOI 10.1145/2810103.2813657, October 2015,

              Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
              Davis, "Recommendation for Pair-Wise Key Establishment
              Schemes Using Discrete Logarithm Cryptography", National
              Institute of Standards and Technology,
              DOI 10.6028/NIST.SP.800-56Ar3, April 2018.

   [Kraw10]   Krawczyk, H., "Cryptographic Extraction and Key
              Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010,
              August 2010, <>.

   [Kraw16]   Krawczyk, H., "A Unilateral-to-Mutual Authentication
              Compiler for Key Exchange (with Applications to Client
              Authentication in TLS 1.3", Proceedings of ACM CCS 2016,
              October 2016, <>.

   [KW16]     Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3",
              Proceedings of EuroS&P 2016, March 2016,

   [LXZFH16]  Li, X., Xu, J., Zhang, Z., Feng, D., and H. Hu, "Multiple
              Handshakes Security of TLS 1.3 Candidates", Proceedings of
              IEEE Symposium on Security and Privacy (San Jose),
              DOI 10.1109/SP.2016.36, May 2016,

   [Mac17]    MacCarthaigh, C., "Security Review of TLS1.3 0-RTT",
              March 2017, <

   [PS18]     Patton, C. and T. Shrimpton, "Partially specified
              channels: The TLS 1.3 record layer without elision", 2018,

              Scott, S., Cremers, C., Horvat, M., and T. van der Merwe,
              "Revision 10: possible attack if client authentication is
              allowed during PSK", message to the TLS mailing list,
              31 October 2015, <
Top   ToC   RFC8446 - Page 116
   [REKEY]    Abdalla, M. and M. Bellare, "Increasing the Lifetime of a
              Key: A Comparative Analysis of the Security of Re-keying
              Techniques", ASIACRYPT 2000, DOI 10.1007/3-540-44448-3_42,
              October 2000.

   [Res17a]   Rescorla, E., "Preliminary data on Firefox TLS 1.3
              Middlebox experiment", message to the TLS mailing list,
              5 December 2017, <

   [Res17b]   Rescorla, E., "More compatibility measurement results",
              message to the TLS mailing list, 22 December 2017,

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346,
              DOI 10.17487/RFC4346, April 2006,

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,

   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
              for Transport Layer Security (TLS)", RFC 4492,
              DOI 10.17487/RFC4492, May 2006,

   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
              January 2008, <>.
Top   ToC   RFC8446 - Page 117
   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,

   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
              Security (DTLS) Extension to Establish Keys for the Secure
              Real-time Transport Protocol (SRTP)", RFC 5764,
              DOI 10.17487/RFC5764, May 2010,

   [RFC5929]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings
              for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,

   [RFC6091]  Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys
              for Transport Layer Security (TLS) Authentication",
              RFC 6091, DOI 10.17487/RFC6091, February 2011,

   [RFC6101]  Freier, A., Karlton, P., and P. Kocher, "The Secure
              Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
              DOI 10.17487/RFC6101, August 2011,

   [RFC6176]  Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
              (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176,
              March 2011, <>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <>.

   [RFC6520]  Seggelmann, R., Tuexen, M., and M. Williams, "Transport
              Layer Security (TLS) and Datagram Transport Layer Security
              (DTLS) Heartbeat Extension", RFC 6520,
              DOI 10.17487/RFC6520, February 2012,

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
Top   ToC   RFC8446 - Page 118
   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <>.

   [RFC7465]  Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
              DOI 10.17487/RFC7465, February 2015,

   [RFC7568]  Barnes, R., Thomson, M., Pironti, A., and A. Langley,
              "Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
              DOI 10.17487/RFC7568, June 2015,

   [RFC7627]  Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
              Langley, A., and M. Ray, "Transport Layer Security (TLS)
              Session Hash and Extended Master Secret Extension",
              RFC 7627, DOI 10.17487/RFC7627, September 2015,

   [RFC7685]  Langley, A., "A Transport Layer Security (TLS) ClientHello
              Padding Extension", RFC 7685, DOI 10.17487/RFC7685,
              October 2015, <>.

   [RFC7924]  Santesson, S. and H. Tschofenig, "Transport Layer Security
              (TLS) Cached Information Extension", RFC 7924,
              DOI 10.17487/RFC7924, July 2016,

   [RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
              Better Connectivity Using Concurrency", RFC 8305,
              DOI 10.17487/RFC8305, December 2017,

   [RFC8422]  Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
              Curve Cryptography (ECC) Cipher Suites for Transport Layer
              Security (TLS) Versions 1.2 and Earlier", RFC 8422,
              DOI 10.17487/RFC8422, August 2018,

   [RFC8447]  Salowey, J. and S. Turner, "IANA Registry Updates for TLS
              and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,

   [RFC8449]  Thomson, M., "Record Size Limit Extension for TLS",
              RFC 8449, DOI 10.17487/RFC8449, August 2018,
Top   ToC   RFC8446 - Page 119
   [RSA]      Rivest, R., Shamir, A., and L. Adleman, "A Method for
              Obtaining Digital Signatures and Public-Key
              Cryptosystems", Communications of the ACM, Vol. 21 No. 2,
              pp. 120-126, DOI 10.1145/359340.359342, February 1978.

   [SIGMA]    Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to
              Authenticated Diffie-Hellman and its Use in the IKE
              Protocols", Proceedings of CRYPTO 2003,
              DOI 10.1007/978-3-540-45146-4_24, August 2003.

   [SLOTH]    Bhargavan, K. and G. Leurent, "Transcript Collision
              Attacks: Breaking Authentication in TLS, IKE, and SSH",
              Network and Distributed System Security
              Symposium (NDSS 2016), DOI 10.14722/ndss.2016.23418,
              February 2016.

   [SSL2]     Hickman, K., "The SSL Protocol", February 1995.

   [TIMING]   Boneh, D. and D. Brumley, "Remote Timing Attacks Are
              Practical", USENIX Security Symposium, August 2003.

              Thomson, M., "Example Handshake Traces for TLS 1.3", Work
              in Progress, draft-ietf-tls-tls13-vectors-06, July 2018.

   [X501]     ITU-T, "Information Technology - Open Systems
              Interconnection - The Directory: Models", ITU-T X.501,
              October 2016, <>.

(next page on part 7)

Next Section