Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8446

The Transport Layer Security (TLS) Protocol Version 1.3

Pages: 160
Proposed Standard
Errata
Obsoletes:  507752466961
Updates:  57056066
Part 8 of 8 – Pages 142 to 160
First   Prev   None

Top   ToC   RFC8446 - Page 142   prevText

Appendix E. Overview of Security Properties

A complete security analysis of TLS is outside the scope of this document. In this appendix, we provide an informal description of the desired properties as well as references to more detailed work in the research literature which provides more formal definitions. We cover properties of the handshake separately from those of the record layer.

E.1. Handshake

The TLS handshake is an Authenticated Key Exchange (AKE) protocol which is intended to provide both one-way authenticated (server-only) and mutually authenticated (client and server) functionality. At the completion of the handshake, each side outputs its view of the following values: - A set of "session keys" (the various secrets derived from the master secret) from which can be derived a set of working keys. - A set of cryptographic parameters (algorithms, etc.). - The identities of the communicating parties. We assume the attacker to be an active network attacker, which means it has complete control over the network used to communicate between the parties [RFC3552]. Even under these conditions, the handshake should provide the properties listed below. Note that these properties are not necessarily independent, but reflect the protocol consumers' needs. Establishing the same session keys: The handshake needs to output the same set of session keys on both sides of the handshake, provided that it completes successfully on each endpoint (see [CK01], Definition 1, part 1). Secrecy of the session keys: The shared session keys should be known only to the communicating parties and not to the attacker (see [CK01], Definition 1, part 2). Note that in a unilaterally authenticated connection, the attacker can establish its own session keys with the server, but those session keys are distinct from those established by the client. Peer authentication: The client's view of the peer identity should reflect the server's identity. If the client is authenticated, the server's view of the peer identity should match the client's identity.
Top   ToC   RFC8446 - Page 143
   Uniqueness of the session keys:  Any two distinct handshakes should
      produce distinct, unrelated session keys.  Individual session keys
      produced by a handshake should also be distinct and independent.

   Downgrade protection:  The cryptographic parameters should be the
      same on both sides and should be the same as if the peers had been
      communicating in the absence of an attack (see [BBFGKZ16],
      Definitions 8 and 9).

   Forward secret with respect to long-term keys:  If the long-term
      keying material (in this case the signature keys in certificate-
      based authentication modes or the external/resumption PSK in PSK
      with (EC)DHE modes) is compromised after the handshake is
      complete, this does not compromise the security of the session key
      (see [DOW92]), as long as the session key itself has been erased.
      The forward secrecy property is not satisfied when PSK is used in
      the "psk_ke" PskKeyExchangeMode.

   Key Compromise Impersonation (KCI) resistance:  In a mutually
      authenticated connection with certificates, compromising the
      long-term secret of one actor should not break that actor's
      authentication of their peer in the given connection (see
      [HGFS15]).  For example, if a client's signature key is
      compromised, it should not be possible to impersonate arbitrary
      servers to that client in subsequent handshakes.

   Protection of endpoint identities:  The server's identity
      (certificate) should be protected against passive attackers.  The
      client's identity should be protected against both passive and
      active attackers.

   Informally, the signature-based modes of TLS 1.3 provide for the
   establishment of a unique, secret, shared key established by an
   (EC)DHE key exchange and authenticated by the server's signature over
   the handshake transcript, as well as tied to the server's identity by
   a MAC.  If the client is authenticated by a certificate, it also
   signs over the handshake transcript and provides a MAC tied to both
   identities.  [SIGMA] describes the design and analysis of this type
   of key exchange protocol.  If fresh (EC)DHE keys are used for each
   connection, then the output keys are forward secret.

   The external PSK and resumption PSK bootstrap from a long-term shared
   secret into a unique per-connection set of short-term session keys.
   This secret may have been established in a previous handshake.  If
   PSK with (EC)DHE key establishment is used, these session keys will
   also be forward secret.  The resumption PSK has been designed so that
   the resumption master secret computed by connection N and needed to
   form connection N+1 is separate from the traffic keys used by
Top   ToC   RFC8446 - Page 144
   connection N, thus providing forward secrecy between the connections.
   In addition, if multiple tickets are established on the same
   connection, they are associated with different keys, so compromise of
   the PSK associated with one ticket does not lead to the compromise of
   connections established with PSKs associated with other tickets.
   This property is most interesting if tickets are stored in a database
   (and so can be deleted) rather than if they are self-encrypted.

   The PSK binder value forms a binding between a PSK and the current
   handshake, as well as between the session where the PSK was
   established and the current session.  This binding transitively
   includes the original handshake transcript, because that transcript
   is digested into the values which produce the resumption master
   secret.  This requires that both the KDF used to produce the
   resumption master secret and the MAC used to compute the binder be
   collision resistant.  See Appendix E.1.1 for more on this.  Note: The
   binder does not cover the binder values from other PSKs, though they
   are included in the Finished MAC.

   TLS does not currently permit the server to send a
   certificate_request message in non-certificate-based handshakes
   (e.g., PSK).  If this restriction were to be relaxed in future, the
   client's signature would not cover the server's certificate directly.
   However, if the PSK was established through a NewSessionTicket, the
   client's signature would transitively cover the server's certificate
   through the PSK binder.  [PSK-FINISHED] describes a concrete attack
   on constructions that do not bind to the server's certificate (see
   also [Kraw16]).  It is unsafe to use certificate-based client
   authentication when the client might potentially share the same
   PSK/key-id pair with two different endpoints.  Implementations
   MUST NOT combine external PSKs with certificate-based authentication
   of either the client or the server unless negotiated by some
   extension.

   If an exporter is used, then it produces values which are unique and
   secret (because they are generated from a unique session key).
   Exporters computed with different labels and contexts are
   computationally independent, so it is not feasible to compute one
   from another or the session secret from the exported value.
   Note: Exporters can produce arbitrary-length values; if exporters are
   to be used as channel bindings, the exported value MUST be large
   enough to provide collision resistance.  The exporters provided in
   TLS 1.3 are derived from the same Handshake Contexts as the early
   traffic keys and the application traffic keys, respectively, and thus
   have similar security properties.  Note that they do not include the
   client's certificate; future applications which wish to bind to the
   client's certificate may need to define a new exporter that includes
   the full handshake transcript.
Top   ToC   RFC8446 - Page 145
   For all handshake modes, the Finished MAC (and, where present, the
   signature) prevents downgrade attacks.  In addition, the use of
   certain bytes in the random nonces as described in Section 4.1.3
   allows the detection of downgrade to previous TLS versions.  See
   [BBFGKZ16] for more details on TLS 1.3 and downgrade.

   As soon as the client and the server have exchanged enough
   information to establish shared keys, the remainder of the handshake
   is encrypted, thus providing protection against passive attackers,
   even if the computed shared key is not authenticated.  Because the
   server authenticates before the client, the client can ensure that if
   it authenticates to the server, it only reveals its identity to an
   authenticated server.  Note that implementations must use the
   provided record-padding mechanism during the handshake to avoid
   leaking information about the identities due to length.  The client's
   proposed PSK identities are not encrypted, nor is the one that the
   server selects.

E.1.1. Key Derivation and HKDF

Key derivation in TLS 1.3 uses HKDF as defined in [RFC5869] and its two components, HKDF-Extract and HKDF-Expand. The full rationale for the HKDF construction can be found in [Kraw10] and the rationale for the way it is used in TLS 1.3 in [KW16]. Throughout this document, each application of HKDF-Extract is followed by one or more invocations of HKDF-Expand. This ordering should always be followed (including in future revisions of this document); in particular, one SHOULD NOT use an output of HKDF-Extract as an input to another application of HKDF-Extract without an HKDF-Expand in between. Multiple applications of HKDF-Expand to some of the same inputs are allowed as long as these are differentiated via the key and/or the labels. Note that HKDF-Expand implements a pseudorandom function (PRF) with both inputs and outputs of variable length. In some of the uses of HKDF in this document (e.g., for generating exporters and the resumption_master_secret), it is necessary that the application of HKDF-Expand be collision resistant; namely, it should be infeasible to find two different inputs to HKDF-Expand that output the same value. This requires the underlying hash function to be collision resistant and the output length from HKDF-Expand to be of size at least 256 bits (or as much as needed for the hash function to prevent finding collisions).
Top   ToC   RFC8446 - Page 146

E.1.2. Client Authentication

A client that has sent authentication data to a server, either during the handshake or in post-handshake authentication, cannot be sure whether the server afterwards considers the client to be authenticated or not. If the client needs to determine if the server considers the connection to be unilaterally or mutually authenticated, this has to be provisioned by the application layer. See [CHHSV17] for details. In addition, the analysis of post-handshake authentication from [Kraw16] shows that the client identified by the certificate sent in the post-handshake phase possesses the traffic key. This party is therefore the client that participated in the original handshake or one to whom the original client delegated the traffic key (assuming that the traffic key has not been compromised).

E.1.3. 0-RTT

The 0-RTT mode of operation generally provides security properties similar to those of 1-RTT data, with the two exceptions that the 0-RTT encryption keys do not provide full forward secrecy and that the server is not able to guarantee uniqueness of the handshake (non-replayability) without keeping potentially undue amounts of state. See Section 8 for mechanisms to limit the exposure to replay.

E.1.4. Exporter Independence

The exporter_master_secret and early_exporter_master_secret are derived to be independent of the traffic keys and therefore do not represent a threat to the security of traffic encrypted with those keys. However, because these secrets can be used to compute any exporter value, they SHOULD be erased as soon as possible. If the total set of exporter labels is known, then implementations SHOULD pre-compute the inner Derive-Secret stage of the exporter computation for all those labels, then erase the [early_]exporter_master_secret, followed by each inner value as soon as it is known that it will not be needed again.

E.1.5. Post-Compromise Security

TLS does not provide security for handshakes which take place after the peer's long-term secret (signature key or external PSK) is compromised. It therefore does not provide post-compromise security [CCG16], sometimes also referred to as backward or future secrecy. This is in contrast to KCI resistance, which describes the security guarantees that a party has after its own long-term secret has been compromised.
Top   ToC   RFC8446 - Page 147

E.1.6. External References

The reader should refer to the following references for analysis of the TLS handshake: [DFGS15], [CHSV16], [DFGS16], [KW16], [Kraw16], [FGSW16], [LXZFH16], [FG17], and [BBK17].

E.2. Record Layer

The record layer depends on the handshake producing strong traffic secrets which can be used to derive bidirectional encryption keys and nonces. Assuming that is true, and the keys are used for no more data than indicated in Section 5.5, then the record layer should provide the following guarantees: Confidentiality: An attacker should not be able to determine the plaintext contents of a given record. Integrity: An attacker should not be able to craft a new record which is different from an existing record which will be accepted by the receiver. Order protection/non-replayability: An attacker should not be able to cause the receiver to accept a record which it has already accepted or cause the receiver to accept record N+1 without having first processed record N. Length concealment: Given a record with a given external length, the attacker should not be able to determine the amount of the record that is content versus padding. Forward secrecy after key change: If the traffic key update mechanism described in Section 4.6.3 has been used and the previous generation key is deleted, an attacker who compromises the endpoint should not be able to decrypt traffic encrypted with the old key. Informally, TLS 1.3 provides these properties by AEAD-protecting the plaintext with a strong key. AEAD encryption [RFC5116] provides confidentiality and integrity for the data. Non-replayability is provided by using a separate nonce for each record, with the nonce being derived from the record sequence number (Section 5.3), with the sequence number being maintained independently at both sides; thus, records which are delivered out of order result in AEAD deprotection failures. In order to prevent mass cryptanalysis when the same plaintext is repeatedly encrypted by different users under the same key (as is commonly the case for HTTP), the nonce is formed by mixing
Top   ToC   RFC8446 - Page 148
   the sequence number with a secret per-connection initialization
   vector derived along with the traffic keys.  See [BT16] for analysis
   of this construction.

   The rekeying technique in TLS 1.3 (see Section 7.2) follows the
   construction of the serial generator as discussed in [REKEY], which
   shows that rekeying can allow keys to be used for a larger number of
   encryptions than without rekeying.  This relies on the security of
   the HKDF-Expand-Label function as a pseudorandom function (PRF).  In
   addition, as long as this function is truly one way, it is not
   possible to compute traffic keys from prior to a key change (forward
   secrecy).

   TLS does not provide security for data which is communicated on a
   connection after a traffic secret of that connection is compromised.
   That is, TLS does not provide post-compromise security/future
   secrecy/backward secrecy with respect to the traffic secret.  Indeed,
   an attacker who learns a traffic secret can compute all future
   traffic secrets on that connection.  Systems which want such
   guarantees need to do a fresh handshake and establish a new
   connection with an (EC)DHE exchange.

E.2.1. External References

The reader should refer to the following references for analysis of the TLS record layer: [BMMRT15], [BT16], [BDFKPPRSZZ16], [BBK17], and [PS18].

E.3. Traffic Analysis

TLS is susceptible to a variety of traffic analysis attacks based on observing the length and timing of encrypted packets [CLINIC] [HCJC16]. This is particularly easy when there is a small set of possible messages to be distinguished, such as for a video server hosting a fixed corpus of content, but still provides usable information even in more complicated scenarios. TLS does not provide any specific defenses against this form of attack but does include a padding mechanism for use by applications: The plaintext protected by the AEAD function consists of content plus variable-length padding, which allows the application to produce arbitrary-length encrypted records as well as padding-only cover traffic to conceal the difference between periods of transmission and periods of silence. Because the padding is encrypted alongside the actual content, an attacker cannot directly determine the length of the padding but may be able to measure it indirectly by the use of timing channels exposed during record processing (i.e., seeing how long it takes to process a record or trickling in records to see
Top   ToC   RFC8446 - Page 149
   which ones elicit a response from the server).  In general, it is not
   known how to remove all of these channels because even a
   constant-time padding removal function will likely feed the content
   into data-dependent functions.  At minimum, a fully constant-time
   server or client would require close cooperation with the
   application-layer protocol implementation, including making that
   higher-level protocol constant time.

   Note: Robust traffic analysis defenses will likely lead to inferior
   performance due to delays in transmitting packets and increased
   traffic volume.

E.4. Side-Channel Attacks

In general, TLS does not have specific defenses against side-channel attacks (i.e., those which attack the communications via secondary channels such as timing), leaving those to the implementation of the relevant cryptographic primitives. However, certain features of TLS are designed to make it easier to write side-channel resistant code: - Unlike previous versions of TLS which used a composite MAC-then- encrypt structure, TLS 1.3 only uses AEAD algorithms, allowing implementations to use self-contained constant-time implementations of those primitives. - TLS uses a uniform "bad_record_mac" alert for all decryption errors, which is intended to prevent an attacker from gaining piecewise insight into portions of the message. Additional resistance is provided by terminating the connection on such errors; a new connection will have different cryptographic material, preventing attacks against the cryptographic primitives that require multiple trials. Information leakage through side channels can occur at layers above TLS, in application protocols and the applications that use them. Resistance to side-channel attacks depends on applications and application protocols separately ensuring that confidential information is not inadvertently leaked.
Top   ToC   RFC8446 - Page 150

E.5. Replay Attacks on 0-RTT

Replayable 0-RTT data presents a number of security threats to TLS- using applications, unless those applications are specifically engineered to be safe under replay (minimally, this means idempotent, but in many cases may also require other stronger conditions, such as constant-time response). Potential attacks include: - Duplication of actions which cause side effects (e.g., purchasing an item or transferring money) to be duplicated, thus harming the site or the user. - Attackers can store and replay 0-RTT messages in order to reorder them with respect to other messages (e.g., moving a delete to after a create). - Exploiting cache timing behavior to discover the content of 0-RTT messages by replaying a 0-RTT message to a different cache node and then using a separate connection to measure request latency, to see if the two requests address the same resource. If data can be replayed a large number of times, additional attacks become possible, such as making repeated measurements of the speed of cryptographic operations. In addition, they may be able to overload rate-limiting systems. For a further description of these attacks, see [Mac17]. Ultimately, servers have the responsibility to protect themselves against attacks employing 0-RTT data replication. The mechanisms described in Section 8 are intended to prevent replay at the TLS layer but do not provide complete protection against receiving multiple copies of client data. TLS 1.3 falls back to the 1-RTT handshake when the server does not have any information about the client, e.g., because it is in a different cluster which does not share state or because the ticket has been deleted as described in Section 8.1. If the application-layer protocol retransmits data in this setting, then it is possible for an attacker to induce message duplication by sending the ClientHello to both the original cluster (which processes the data immediately) and another cluster which will fall back to 1-RTT and process the data upon application-layer replay. The scale of this attack is limited by the client's willingness to retry transactions and therefore only allows a limited amount of duplication, with each copy appearing as a new connection at the server.
Top   ToC   RFC8446 - Page 151
   If implemented correctly, the mechanisms described in Sections 8.1
   and 8.2 prevent a replayed ClientHello and its associated 0-RTT data
   from being accepted multiple times by any cluster with consistent
   state; for servers which limit the use of 0-RTT to one cluster for a
   single ticket, then a given ClientHello and its associated 0-RTT data
   will only be accepted once.  However, if state is not completely
   consistent, then an attacker might be able to have multiple copies of
   the data be accepted during the replication window.  Because clients
   do not know the exact details of server behavior, they MUST NOT send
   messages in early data which are not safe to have replayed and which
   they would not be willing to retry across multiple 1-RTT connections.

   Application protocols MUST NOT use 0-RTT data without a profile that
   defines its use.  That profile needs to identify which messages or
   interactions are safe to use with 0-RTT and how to handle the
   situation when the server rejects 0-RTT and falls back to 1-RTT.

   In addition, to avoid accidental misuse, TLS implementations MUST NOT
   enable 0-RTT (either sending or accepting) unless specifically
   requested by the application and MUST NOT automatically resend 0-RTT
   data if it is rejected by the server unless instructed by the
   application.  Server-side applications may wish to implement special
   processing for 0-RTT data for some kinds of application traffic
   (e.g., abort the connection, request that data be resent at the
   application layer, or delay processing until the handshake
   completes).  In order to allow applications to implement this kind of
   processing, TLS implementations MUST provide a way for the
   application to determine if the handshake has completed.

E.5.1. Replay and Exporters

Replays of the ClientHello produce the same early exporter, thus requiring additional care by applications which use these exporters. In particular, if these exporters are used as an authentication channel binding (e.g., by signing the output of the exporter), an attacker who compromises the PSK can transplant authenticators between connections without compromising the authentication key. In addition, the early exporter SHOULD NOT be used to generate server-to-client encryption keys because that would entail the reuse of those keys. This parallels the use of the early application traffic keys only in the client-to-server direction.
Top   ToC   RFC8446 - Page 152

E.6. PSK Identity Exposure

Because implementations respond to an invalid PSK binder by aborting the handshake, it may be possible for an attacker to verify whether a given PSK identity is valid. Specifically, if a server accepts both external-PSK handshakes and certificate-based handshakes, a valid PSK identity will result in a failed handshake, whereas an invalid identity will just be skipped and result in a successful certificate handshake. Servers which solely support PSK handshakes may be able to resist this form of attack by treating the cases where there is no valid PSK identity and where there is an identity but it has an invalid binder identically.

E.7. Sharing PSKs

TLS 1.3 takes a conservative approach to PSKs by binding them to a specific KDF. By contrast, TLS 1.2 allows PSKs to be used with any hash function and the TLS 1.2 PRF. Thus, any PSK which is used with both TLS 1.2 and TLS 1.3 must be used with only one hash in TLS 1.3, which is less than optimal if users want to provision a single PSK. The constructions in TLS 1.2 and TLS 1.3 are different, although they are both based on HMAC. While there is no known way in which the same PSK might produce related output in both versions, only limited analysis has been done. Implementations can ensure safety from cross-protocol related output by not reusing PSKs between TLS 1.3 and TLS 1.2.

E.8. Attacks on Static RSA

Although TLS 1.3 does not use RSA key transport and so is not directly susceptible to Bleichenbacher-type attacks [Blei98], if TLS 1.3 servers also support static RSA in the context of previous versions of TLS, then it may be possible to impersonate the server for TLS 1.3 connections [JSS15]. TLS 1.3 implementations can prevent this attack by disabling support for static RSA across all versions of TLS. In principle, implementations might also be able to separate certificates with different keyUsage bits for static RSA decryption and RSA signature, but this technique relies on clients refusing to accept signatures using keys in certificates that do not have the digitalSignature bit set, and many clients do not enforce this restriction.
Top   ToC   RFC8446 - Page 153

Contributors

Martin Abadi University of California, Santa Cruz abadi@cs.ucsc.edu Christopher Allen (co-editor of TLS 1.0) Alacrity Ventures ChristopherA@AlacrityManagement.com Richard Barnes Cisco rlb@ipv.sx Steven M. Bellovin Columbia University smb@cs.columbia.edu David Benjamin Google davidben@google.com Benjamin Beurdouche INRIA & Microsoft Research benjamin.beurdouche@ens.fr Karthikeyan Bhargavan (editor of [RFC7627]) INRIA karthikeyan.bhargavan@inria.fr Simon Blake-Wilson (co-author of [RFC4492]) BCI sblakewilson@bcisse.com Nelson Bolyard (co-author of [RFC4492]) Sun Microsystems, Inc. nelson@bolyard.com Ran Canetti IBM canetti@watson.ibm.com
Top   ToC   RFC8446 - Page 154
   Matt Caswell
   OpenSSL
   matt@openssl.org

   Stephen Checkoway
   University of Illinois at Chicago
   sfc@uic.edu

   Pete Chown
   Skygate Technology Ltd
   pc@skygate.co.uk

   Katriel Cohn-Gordon
   University of Oxford
   me@katriel.co.uk

   Cas Cremers
   University of Oxford
   cas.cremers@cs.ox.ac.uk

   Antoine Delignat-Lavaud
   (co-author of [RFC7627])
   INRIA
   antdl@microsoft.com

   Tim Dierks
   (co-author of TLS 1.0, co-editor of TLS 1.1 and 1.2)
   Independent
   tim@dierks.org

   Roelof DuToit
   Symantec Corporation
   roelof_dutoit@symantec.com

   Taher Elgamal
   Securify
   taher@securify.com

   Pasi Eronen
   Nokia
   pasi.eronen@nokia.com

   Cedric Fournet
   Microsoft
   fournet@microsoft.com
Top   ToC   RFC8446 - Page 155
   Anil Gangolli
   anil@busybuddha.org

   David M. Garrett
   dave@nulldereference.com

   Illya Gerasymchuk
   Independent
   illya@iluxonchik.me

   Alessandro Ghedini
   Cloudflare Inc.
   alessandro@cloudflare.com

   Daniel Kahn Gillmor
   ACLU
   dkg@fifthhorseman.net

   Matthew Green
   Johns Hopkins University
   mgreen@cs.jhu.edu

   Jens Guballa
   ETAS
   jens.guballa@etas.com

   Felix Guenther
   TU Darmstadt
   mail@felixguenther.info

   Vipul Gupta
   (co-author of [RFC4492])
   Sun Microsystems Laboratories
   vipul.gupta@sun.com

   Chris Hawk
   (co-author of [RFC4492])
   Corriente Networks LLC
   chris@corriente.net

   Kipp Hickman

   Alfred Hoenes

   David Hopwood
   Independent Consultant
   david.hopwood@blueyonder.co.uk
Top   ToC   RFC8446 - Page 156
   Marko Horvat
   MPI-SWS
   mhorvat@mpi-sws.org

   Jonathan Hoyland
   Royal Holloway, University of London
   jonathan.hoyland@gmail.com

   Subodh Iyengar
   Facebook
   subodh@fb.com

   Benjamin Kaduk
   Akamai Technologies
   kaduk@mit.edu

   Hubert Kario
   Red Hat Inc.
   hkario@redhat.com

   Phil Karlton
   (co-author of SSL 3.0)

   Leon Klingele
   Independent
   mail@leonklingele.de

   Paul Kocher
   (co-author of SSL 3.0)
   Cryptography Research
   paul@cryptography.com

   Hugo Krawczyk
   IBM
   hugokraw@us.ibm.com

   Adam Langley
   (co-author of [RFC7627])
   Google
   agl@google.com

   Olivier Levillain
   ANSSI
   olivier.levillain@ssi.gouv.fr
Top   ToC   RFC8446 - Page 157
   Xiaoyin Liu
   University of North Carolina at Chapel Hill
   xiaoyin.l@outlook.com

   Ilari Liusvaara
   Independent
   ilariliusvaara@welho.com

   Atul Luykx
   K.U. Leuven
   atul.luykx@kuleuven.be

   Colm MacCarthaigh
   Amazon Web Services
   colm@allcosts.net

   Carl Mehner
   USAA
   carl.mehner@usaa.com

   Jan Mikkelsen
   Transactionware
   janm@transactionware.com

   Bodo Moeller
   (co-author of [RFC4492])
   Google
   bodo@acm.org

   Kyle Nekritz
   Facebook
   knekritz@fb.com

   Erik Nygren
   Akamai Technologies
   erik+ietf@nygren.org

   Magnus Nystrom
   Microsoft
   mnystrom@microsoft.com

   Kazuho Oku
   DeNA Co., Ltd.
   kazuhooku@gmail.com
Top   ToC   RFC8446 - Page 158
   Kenny Paterson
   Royal Holloway, University of London
   kenny.paterson@rhul.ac.uk

   Christopher Patton
   University of Florida
   cjpatton@ufl.edu

   Alfredo Pironti
   (co-author of [RFC7627])
   INRIA
   alfredo.pironti@inria.fr

   Andrei Popov
   Microsoft
   andrei.popov@microsoft.com

   Marsh Ray
   (co-author of [RFC7627])
   Microsoft
   maray@microsoft.com

   Robert Relyea
   Netscape Communications
   relyea@netscape.com

   Kyle Rose
   Akamai Technologies
   krose@krose.org

   Jim Roskind
   Amazon
   jroskind@amazon.com

   Michael Sabin

   Joe Salowey
   Tableau Software
   joe@salowey.net

   Rich Salz
   Akamai
   rsalz@akamai.com

   David Schinazi
   Apple Inc.
   dschinazi@apple.com
Top   ToC   RFC8446 - Page 159
   Sam Scott
   Royal Holloway, University of London
   me@samjs.co.uk

   Thomas Shrimpton
   University of Florida
   teshrim@ufl.edu

   Dan Simon
   Microsoft, Inc.
   dansimon@microsoft.com

   Brian Smith
   Independent
   brian@briansmith.org

   Brian Sniffen
   Akamai Technologies
   ietf@bts.evenmere.org

   Nick Sullivan
   Cloudflare Inc.
   nick@cloudflare.com

   Bjoern Tackmann
   University of California, San Diego
   btackmann@eng.ucsd.edu

   Tim Taubert
   Mozilla
   ttaubert@mozilla.com

   Martin Thomson
   Mozilla
   mt@mozilla.com

   Hannes Tschofenig
   Arm Limited
   Hannes.Tschofenig@arm.com

   Sean Turner
   sn3rd
   sean@sn3rd.com

   Steven Valdez
   Google
   svaldez@google.com
Top   ToC   RFC8446 - Page 160
   Filippo Valsorda
   Cloudflare Inc.
   filippo@cloudflare.com

   Thyla van der Merwe
   Royal Holloway, University of London
   tjvdmerwe@gmail.com

   Victor Vasiliev
   Google
   vasilvv@google.com

   Hoeteck Wee
   Ecole Normale Superieure, Paris
   hoeteck@alum.mit.edu

   Tom Weinstein

   David Wong
   NCC Group
   david.wong@nccgroup.trust

   Christopher A. Wood
   Apple Inc.
   cawood@apple.com

   Tim Wright
   Vodafone
   timothy.wright@vodafone.com

   Peter Wu
   Independent
   peter@lekensteyn.nl

   Kazu Yamamoto
   Internet Initiative Japan Inc.
   kazu@iij.ad.jp

Author's Address

Eric Rescorla Mozilla Email: ekr@rtfm.com