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 |
GENART Last Call review
(of
-24)
by Dale Worley
Ready w/nits
|
||
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]