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.

   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

   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.

   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).

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.

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

   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

   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.

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.

   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.

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.

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

   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

   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

   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

   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

   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

   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

   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