Projecting a Secure Future: TLS 1.2
It has been nearly five years since fTLD Registry Services published its original Security Requirements (the “Requirements”), a comprehensive collection of policy and technical controls designed to safeguard the .BANK and .INSURANCE internet web domains. Since the original publication in 2011, the Requirements have gone through two revisions and a third is likely to occur in early 2017.
A key principle in the creation of the Requirements is an obligation for registrants (i.e., entities that register domain names) to keep current with modern cryptography in all publicly accessible communications such as websites and email. Transport Layer Security (TLS), the successor to Secure Sockets Layer (SSL), is the most commonly deployed public key technology and provides confidentiality and integrity to online communications. TLS, native to all modern web browsers such as Chrome, Firefox and internet Explorer, is the foundation that secures the vast majority of transactions conducted over the internet.
Since 2011, TLS version 1.1 has been considered the “floor” for strong security practices in the .BANK and .INSURANCE environment. However, with additions of RC4 and SHA-1 (and CBC to be formally added soon) to fTLD’s excluded ciphers list (Requirement #29) due to security vulnerabilities, TLS 1.1, in practice, no longer has any hardened configurations available leading many security-conscious organizations to look to newer versions of the cryptographic protocol.
The good news is that TLS 1.2, published in August 2008, is a capable drop-in replacement. Other than the cost in time and money regenerating and implementing a new public key certificate from a change control perspective, the transition to TLS 1.2 should be relatively seamless and without interruption or impact for customers using modern web browsers.
In fact, moving to TLS 1.2 opens the possibility for .BANK and .INSURANCE registrants to implement “Forward Secrecy” (Diffie–Hellman and elliptic curve Diffie-Hellman), the idea that a session key derived from a set of long-term public and private keys will not be compromised if the private keys are compromised in other sessions in the future.
For registrants in the planning stages for deployment of their .BANK and .INSURANCE domains, or for new and existing online services, it’s advisable they skip over TLS 1.1 and expedite adoption of TLS 1.2. In the meantime, registrants should avoid using CBC, SHA-1, RC4 or any other fTLD excluded cipher suite in all legacy TLS 1.1 deployments.
By Andrew Kennedy, Financial Services Roundtable/BITS Cybersecurity Advisor to fTLD
