IETF Approves TLS 1.3

This post was originally published on this site

The Internet Engineering Task Force (IETF) last week announced the approval of version 1.3 of the Transport Layer Security (TLS) traffic encryption protocol. The Internet standards organization has been analyzing proposals for TLS 1.3 since April 2014 and it took 28 drafts to get it to its current form.

TLS is designed to allow client and server applications to communicate over the Internet securely. It provides authentication, confidentiality, and integrity mechanisms that should prevent eavesdropping and tampering, even by an attacker who has complete control over the network.IETF approves TLS 1.3

There are nearly a dozen major functional differences between TLS 1.2 and TLS 1.3, including ones that should improve performance and eliminate the possibility of certain types of attacks, such as the recently disclosed ROBOT method. The most important changes have been described by the IETF as follows:

  • The list of supported symmetric algorithms has been pruned of all algorithms that are considered legacy. Those that remain all use Authenticated Encryption with Associated Data (AEAD) algorithms. The ciphersuite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with the key derivation function and HMAC.
  • A 0-RTT mode was added, saving a round-trip at connection setup for some application data, at the cost of certain security properties.
  • Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
  • All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtension message allows various extensions previously sent in clear in the ServerHello to also enjoy confidentiality protection from active attackers.
  • The key derivation functions have been re-designed. The new design allows easier analysis by cryptographers due to their improved key separation properties. The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is used as an underlying primitive.
  • The handshake state machine has been significantly restructured to be more consistent and to remove superfluous messages such as ChangeCipherSpec (except when needed for middlebox compatibility).
  • Elliptic curve algorithms are now in the base spec and new signature algorithms, such as ed25519 and ed448, are included. TLS 1.3 removed point format negotiation in favor of a single point format for each curve.
  • Other cryptographic improvements including the removal of compression and custom DHE groups, changing the RSA padding to use RSASSA-PSS, and the removal of DSA.
  • The TLS 1.2 version negotiation mechanism has been deprecated in favor of a version list in an extension. This increases compatibility with existing servers that incorrectly implemented version negotiation.
  • Session resumption with and without server-side state as well as the PSK-based ciphersuites of earlier TLS versions have been replaced by a single new PSK exchange.

The most controversial of these changes is related to the introduction of the 0-RTT (zero round trip time resumption) mode. This feature brings significant improvements in terms of speed, particularly in the case of resumed connections, but it makes the connection slightly less secure.

The main concern are replay attacks, but experts believe the risk is manageable and website administrators should not have anything to worry about. However, some members of the IETF believe there are bound to be successful attacks against existing mitigations in the future. Cloudflare published a blog post last year detailing 0-RTT benefits and risks.

Cloudflare announced support for TLS 1.3 in September 2016, but the company reported in late December 2017 that major web browsers had yet to enable the new version of the protocol by default, with only 0.06% of the traffic passing through its network leveraging TLS 1.3.

Cloudflare has blamed this delay on network appliances that need to intercept HTTPS traffic on corporate networks, and the original design of TLS 1.3. Poor implementation of TLS 1.3 has been known to cause serious problems.

The OpenSSL Project announced support for TLS 1.3 in February when it unveiled OpenSSL 1.1.1, which is currently in alpha.

view counter

Eduard Kovacs (@EduardKovacs) is a contributing editor at SecurityWeek. He worked as a high school IT teacher for two years before starting a career in journalism as Softpedia’s security news reporter. Eduard holds a bachelor’s degree in industrial informatics and a master’s degree in computer techniques applied in electrical engineering.

Previous Columns by Eduard Kovacs: