Design issues for hybrid key exchange in TLS 1.3
draft-stebila-tls-hybrid-design-01
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Expired & archived
|
|
|---|---|---|---|
| Authors | Douglas Stebila , Scott Fluhrer , Shay Gueron | ||
| Last updated | 2020-01-09 (Latest revision 2019-07-08) | ||
| Replaced by | draft-ietf-tls-hybrid-design | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Associated None milestone |
|
||
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken, and is motivated by transition to post-quantum cryptography. This document categorizes various design considerations for using hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3 and outlines two concrete instantiations for consideration.
Authors
Douglas Stebila
Scott Fluhrer
Shay Gueron
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)