Skip to main content

The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8446.
Authors Tim Dierks , Eric Rescorla
Last updated 2014-07-21 (Latest revision 2014-07-08)
Replaces draft-ietf-tls-rfc5246-bis
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 8446 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-tls-tls13-02
F.2.  Protecting Application Data

   The master_secret is hashed with the ClientHello.random and
   ServerHello.random to produce unique record protection secrets for
   each connection.

   Outgoing data is protected using an AEAD algorithm before
   transmission.  The authentication data includes the sequence number,
   message type, message length, and the message contents.  The message
   type field is necessary to ensure that messages intended for one TLS
   record layer client are not redirected to another.  The sequence
   number ensures that attempts to delete or reorder messages will be
   detected.  Since sequence numbers are 64 bits long, they should never
   overflow.  Messages from one party cannot be inserted into the
   other's output, since they use independent keys.

F.3.  Denial of Service

   TLS is susceptible to a number of denial-of-service (DoS) attacks.
   In particular, an attacker who initiates a large number of TCP
   connections can cause a server to consume large amounts of CPU doing
   asymmetric crypto operations.  However, because TLS is generally used
   over TCP, it is difficult for the attacker to hide his point of
   origin if proper TCP SYN randomization is used [RFC1948] by the TCP
   stack.

   Because TLS runs over TCP, it is also susceptible to a number of DoS
   attacks on individual connections.  In particular, attackers can
   forge RSTs, thereby terminating connections, or forge partial TLS
   records, thereby causing the connection to stall.  These attacks
   cannot in general be defended against by a TCP-using protocol.
   Implementors or users who are concerned with this class of attack
   should use IPsec AH [RFC4302] or ESP [RFC4303].

F.4.  Final Notes

   For TLS to be able to provide a secure connection, both the client
   and server systems, keys, and applications must be secure.  In
   addition, the implementation must be free of security errors.

   The system is only as strong as the weakest key exchange and
   authentication algorithm supported, and only trustworthy
   cryptographic functions should be used.  Short public keys and
   anonymous servers should be used with great caution.  Implementations
   and users must be careful when deciding which certificates and
   certificate authorities are acceptable; a dishonest certificate
   authority can do tremendous damage.

Dierks & Rescorla        Expires January 8, 2015               [Page 88]
Internet-Draft                     TLS                         July 2014

Appendix G.  Working Group Information

   The discussion list for the IETF TLS working group is located at the
   e-mail address tls@ietf.org [2].  Information on the group and
   information on how to subscribe to the list is at
   https://www1.ietf.org/mailman/listinfo/tls

   Archives of the list can be found at:
   http://www.ietf.org/mail-archive/web/tls/current/index.html

Appendix H.  Contributors

   Christopher Allen (co-editor of TLS 1.0)
   Alacrity Ventures
   ChristopherA@AlacrityManagement.com

   Martin Abadi
   University of California, Santa Cruz
   abadi@cs.ucsc.edu

   Steven M. Bellovin
   Columbia University
   smb@cs.columbia.edu

   Simon Blake-Wilson
   BCI
   sblakewilson@bcisse.com

   Ran Canetti
   IBM
   canetti@watson.ibm.com

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

   Taher Elgamal
   taher@securify.com
   Securify

   Pasi Eronen
   pasi.eronen@nokia.com
   Nokia

   Anil Gangolli
   anil@busybuddha.org

   Kipp Hickman

Dierks & Rescorla        Expires January 8, 2015               [Page 89]
Internet-Draft                     TLS                         July 2014

   Alfred Hoenes

   David Hopwood
   Independent Consultant
   david.hopwood@blueyonder.co.uk

   Phil Karlton (co-author of SSLv3)

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

   Hugo Krawczyk
   IBM
   hugo@ee.technion.ac.il

   Jan Mikkelsen
   Transactionware
   janm@transactionware.com

   Magnus Nystrom
   RSA Security
   magnus@rsasecurity.com

   Robert Relyea
   Netscape Communications
   relyea@netscape.com

   Jim Roskind
   Netscape Communications
   jar@netscape.com

   Michael Sabin

   Dan Simon
   Microsoft, Inc.
   dansimon@microsoft.com

   Tom Weinstein

   Tim Wright
   Vodafone
   timothy.wright@vodafone.com

Dierks & Rescorla        Expires January 8, 2015               [Page 90]
Internet-Draft                     TLS                         July 2014

Authors' Addresses

   Tim Dierks
   Independent

   EMail: tim@dierks.org

   Eric Rescorla
   RTFM, Inc.

   EMail: ekr@rtfm.com

Dierks & Rescorla        Expires January 8, 2015               [Page 91]