[Cryptography] At what point should people not use TLS?

Thierry Moreau thierry.moreau at connotech.com
Wed Apr 6 08:05:41 EDT 2016


On 06/04/16 03:00 AM, david wong wrote:
>
> What
> about the peer-review and all the research done around TLS and its
> implementations?
>
> But then it might makes sense, if the protocol is simple enough, to try
> and build that subset of TLS.
> What do you people think?
>

Hi!

Those who study TLS when they are envisionning a new secure protocol 
based on public key cryptography, IMHO, completely miss the important 
lessons from the crypto science.

Below is an overview summary, excerpt from a draft document in 
preparation. Comments welcome.

Regards,

- Thierry Moreau

Classical Authenticated Diffie-Hellman (D-H) Exchange
=====================================================

The original D-H cryptosystem publication [...] has been followed by the 
development of workable public key digital signatures and the concept of 
security certificates for automated trust decisions for a remote party 
public signature key. The authenticated D-H exchange combines these 
developments for the establishment of an authenticated shared session 
key between a local and remote party, with the authentication based 
solely on a trusted certification authority (CA) public key.

Here is the historic perspective. The industrial application of public 
key cryptography concepts for telecommunications were first envisioned 
for secure telephony, both as a US government controlled technology with 
the STU-III model ([1]) and as the then emerging ISDN technology (e.g. 
references 41 and 81 in [1]). Indeed, two detailed disclosures of the 
basic authenticated D-H exchange were made by researchers at two 
telephone equipment manufacturer research organisations, namely Bell 
Northern Research ([2]) and AT&T ([3]). The Bell Northern publication is 
known as the Station-to-Station (STS) protocol and is acknowledged as a 
source of inspiration for the later developments. Notably, this basic 
scheme was first standardized in the OSI network layer security protocol 
(NLSP, [4]) and transport layer security protocol (TLSP, [5]). These 
references are not to be confused with the reference [6] which is 
sometimes cited as an STS variant while actually making no use of the 
Diffie-Hellman cryptosystem. With the domination of Internet protocols 
over ISDN and OSI came the adoption of the SSL protocol that got IETF 
endorsement as the TLS protocol, without a connection to STS. The latter 
made a comeback in the IPSEC protocol suite as IKE and then IKE version 
2 ([7]). It is in this form that the authenticated D-H exchange is 
present in modern networks, with security critical improvements 
explained in an essential article by Hugo Krawczyk ([8]). This state of 
the art gets a further endorsement in the Host Identity Protocol (HIP, 
[9]), a leading edge research proposal for secure Internet protocol.

However the seemingly endless IPSEC protocol standardization details 
obscure the essential characteristics of the authenticated D-H exchange, 
notably due to a dedication to interoperability in presence of many 
implementation options. A trend in the IPSEC options expansion is the 
adoption of optional authentication schemes other than public key 
cryptography digital signatures, e.g. Extensible Authentication Protocol 
(EAP). Also, the IKE protocol has provisions for cryptographic key 
management beyond the initial authenticated D-H exchange, notably for 
rekeying and establishment of parallel logical secure channels.

The relatively small usage of the genuine authenticated D-H exchange 
might be explained by the practical deployment challenge of digital 
signature key pairs for every communicating entities (client security 
certificates in the TLS jargon which puts the user mental model remote 
from the inner working of digital signatures). In this historical 
perspective, the authenticated D-H exchange would be the core of the 
lost art of classical public key cryptography. Indeed, one may notice 
the prudent recommendation in section 5.2 of the original STS 
publication ([2]) that anticipated to the very root cause of the Logjam 
major vulnerability in Internet security protocols uncovered in 2015 ([10]).

Another approach to justify the relevance of the authenticated D-H 
exchange is bottom up, starting from a naive desire to establish a 
scrambled communication channel between two parties on the Internet. By 
some iterative learning and creativity process, the pitfalls of an home 
brewed encryption scheme might be understood and fixed. That would start 
with a conventional symmetric cipher, then the addition of symmetric 
integrity protection and the naked Diffie-Hellman exchange for setting 
up a shared key (a rudimentary hybrid cryptosystem). The MITM 
vulnerability would come next, and so on until the full authenticated 
D-H exchange is considered an essential requirement for key 
establishment. In this process, the benefits of forward secrecy and 
desirability of traffic flow confidentiality would further disqualify 
alternative solutions. At the end would remain the authenticated D-H 
exchange for key establishment and a bulk secure communication scheme 
for the actual data transmission (any rekeying requirement is explicitly 
omitted and may be the subject of further study). In the IPSEC world, 
the latter is the Encapsulating Security Payload (ESP) protocol [11].

While standardization bodies adopted the reference [8] as a yardstick 
for authenticated and key agreement using public key cryptography, a 
little noticed alternate academic contribution attracted less attention: 
under the leadership of professor Lein Harn, the mutual authentication 
of a Diffie-Hellman shared secret is wholly achieved with discrete 
logarithm based cryptography, i.e. neither hash functions nor factoring 
based cryptography are needed. The seminal idea of a digital signature 
scheme specialized for Diffie-Hellman shared secrets is in the reference 
[12]. However, when applied to mutual authentication in a Diffie-Hellman 
exchange, an attack ruins the forward secrecy property. This was fixed 
in reference [13], and a more elaborate proposal came in reference [14]. 
This alternate research direction hints that the standardization 
solution may not be the last word in every aspects. It may also help the 
structured study of the diversified set of discrete log cryptosystems.

References

[1] Whitfield Diffie, "The First Ten Years of Public-Key Cryptography", 
invited paper, Proceedings of the IEEE, Vol. 76, No. 5, MAY 1988.

[2] Whitfield Diffie, Paul C. Van Oorschot, and Michael J. Wiener 
"Authentication and Authenticated Key Exchanges", in Designs, Codes and 
Cryptography, 2, 107-125 (1992) (received by editor Nov. 22, 1991 and 
revised Mar. 6, 1992).

[3] Steven M. Bellovin and Michael Merritt, "Cryptographic protocol for 
secure communications", United States Patent number 5,241,599, August 
31, 1993, filed October 2, 1991.

[4] ITU-T Recommendation X.273 (1994) | ISO/IEC 11577:1995, "Information 
technology - Open Systems Interconnection - Network layer security 
protocol", available at http://www.itu.int/rec/T-REC-X.273-199407-I/en.

[5] ITU-T Recommendation X.274 (1994) | ISO/IEC 10736:1995, "Information 
technology - Telecommunications and information exchange between systems 
- Transport layer security protocol", available at 
http://www.itu.int/rec/T-REC-X.274-199407-I/en.

[6] ISO/IEC 9798-3:1993, "Entity authentication mechanisms -- Part 3: 
Entity authentication using asymmetric techniques".

[7] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, and T. Kivinen, "Internet 
Key Exchange Protocol Version 2 (IKEv2)", IETF RFC 7296, Internet 
Engineering Task Force (IETF), October 2014, available at 
https://tools.ietf.org/html/rfc7296.

[8] Hugo Krawczyk, "SIGMA: the 'SIGn-and-MAc' Approach to Authenticated 
Diffie-Hellman and its Use in the IKE Protocols", 2003, proceedings of 
Crypto'03 (LNCS Series, Vol. 2729), extended version available at 
http://www.ee.technion.ac.il/~hugo/sigma.html.

[9] R. Moskowitz (editor), T. Heer, P. Jokela, and T. Henderson, "Host 
Identity Protocol Version 2 (HIPv2)", IETF RFC 7401, Internet 
Engineering Task Force (IETF), April 2015, available at 
https://tools.ietf.org/html/rfc7401.

[10] David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick 
Gaudry, Matthew Green, J. Alex Halderman, Nadia Heninger, Drew 
Springall, Emmanuel Thom'e, Luke Valenta, Benjamin VanderSloot, Eric 
Wustrow, Santiago Zanella-B'eguelin, and Paul Zimmermann, "Imperfect 
Forward Secrecy: How Diffie-Hellman Fails in Practice" in proceedings of 
22nd ACM Conference on Computer and Communications Security, October, 
2015, DOI: http://dx.doi.org/10.1145/2810103.2813707, also visit 
http://weakdh.org.

[11] S. Kent, "IP Encapsulating Security Payload (ESP)", IETF RFC 4303, 
Network Working Group, December 2005, available at 
https://tools.ietf.org/html/rfc4303.

[12] L. Harn, "Digital signature for Diffie-Hellman public keys without 
using a one-way function", Electron. Lett., vol. 33 (1997), no 2, pp 
125-126.

[13] L. Harn and H.-Y. Lin, "Authenticated key agreement without using 
one-way hash functions", Electron. Lett., vol. 37 (2001), no. 10, pp 
629-630.

[14] L. Harn, W.-J. Hsin, and M. Manish, "Authenticated Diffie-Hellman 
key agreement protocol using single cryptographic assumption", IEE 
Proceedings Communications, Vol. 152, No. 4, pp. 404-410, Aug 2005.

References 1, 2, 11, 12, 13, and 14 may be available in digital format 
through one's preferred search engine.
=== The End ===



More information about the cryptography mailing list