|
1 | 1 | target = "https://www.rfc-editor.org/rfc/rfc4492#section-2" |
2 | 2 |
|
3 | | -# 2. Key Exchange Algorithms |
| 3 | +# Key Exchange Algorithms |
4 | 4 | # |
5 | | -# This document introduces five new ECC-based key exchange algorithms |
6 | | -# for TLS. All of them use ECDH to compute the TLS premaster secret, |
7 | | -# and they differ only in the lifetime of ECDH keys (long-term or |
8 | | -# ephemeral) and the mechanism (if any) used to authenticate them. The |
9 | | -# derivation of the TLS master secret from the premaster secret and the |
10 | | -# subsequent generation of bulk encryption/MAC keys and initialization |
11 | | -# vectors is independent of the key exchange algorithm and not impacted |
12 | | -# by the introduction of ECC. |
13 | | -# |
14 | | -# The table below summarizes the new key exchange algorithms, which |
15 | | -# mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2] and |
16 | | -# [3]), respectively. |
17 | | -# |
18 | | -# Key |
19 | | -# Exchange |
20 | | -# Algorithm Description |
21 | | -# --------- ----------- |
22 | | -# |
23 | | -# ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. |
24 | | -# |
25 | | -# ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. |
26 | | -# |
27 | | -# ECDH_RSA Fixed ECDH with RSA-signed certificates. |
28 | | -# |
29 | | -# ECDHE_RSA Ephemeral ECDH with RSA signatures. |
30 | | -# |
31 | | -# ECDH_anon Anonymous ECDH, no signatures. |
32 | | -# |
33 | | -# Table 2: ECC Key Exchange Algorithms |
34 | | -# |
35 | | -# The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward |
36 | | -# secrecy. With ECDHE_RSA, a server can reuse its existing RSA |
37 | | -# certificate and easily comply with a constrained client's elliptic |
38 | | -# curve preferences (see Section 4). However, the computational cost |
39 | | -# |
40 | | -# incurred by a server is higher for ECDHE_RSA than for the traditional |
41 | | -# RSA key exchange, which does not provide forward secrecy. |
42 | | -# |
43 | | -# The ECDH_RSA mechanism requires a server to acquire an ECC |
44 | | -# certificate, but the certificate issuer can still use an existing RSA |
45 | | -# key for signing. This eliminates the need to update the keys of |
46 | | -# trusted certification authorities accepted by TLS clients. The |
47 | | -# ECDH_ECDSA mechanism requires ECC keys for the server as well as the |
48 | | -# certification authority and is best suited for constrained devices |
49 | | -# unable to support RSA. |
50 | | -# |
51 | | -# The anonymous key exchange algorithm does not provide authentication |
52 | | -# of the server or the client. Like other anonymous TLS key exchanges, |
53 | | -# it is subject to man-in-the-middle attacks. Implementations of this |
54 | | -# algorithm SHOULD provide authentication by other means. |
55 | | -# |
56 | | -# Note that there is no structural difference between ECDH and ECDSA |
57 | | -# keys. A certificate issuer may use X.509 v3 keyUsage and |
58 | | -# extendedKeyUsage extensions to restrict the use of an ECC public key |
59 | | -# to certain computations [15]. This document refers to an ECC key as |
60 | | -# ECDH-capable if its use in ECDH is permitted. ECDSA-capable is |
61 | | -# defined similarly. |
62 | | -# |
63 | | -# Client Server |
64 | | -# ------ ------ |
65 | | -# |
66 | | -# ClientHello --------> |
67 | | -# ServerHello |
68 | | -# Certificate* |
69 | | -# ServerKeyExchange* |
70 | | -# CertificateRequest*+ |
71 | | -# <-------- ServerHelloDone |
72 | | -# Certificate*+ |
73 | | -# ClientKeyExchange |
74 | | -# CertificateVerify*+ |
75 | | -# [ChangeCipherSpec] |
76 | | -# Finished --------> |
77 | | -# [ChangeCipherSpec] |
78 | | -# <-------- Finished |
79 | | -# |
80 | | -# Application Data <-------> Application Data |
81 | | -# |
82 | | -# * message is not sent under some conditions |
83 | | -# + message is not sent unless client authentication |
84 | | -# is desired |
85 | | -# |
86 | | -# Figure 1: Message flow in a full TLS handshake |
87 | | -# |
88 | | -# Figure 1 shows all messages involved in the TLS key establishment |
89 | | -# protocol (aka full handshake). The addition of ECC has direct impact |
90 | | -# only on the ClientHello, the ServerHello, the server's Certificate |
91 | | -# message, the ServerKeyExchange, the ClientKeyExchange, the |
92 | | -# CertificateRequest, the client's Certificate message, and the |
93 | | -# CertificateVerify. Next, we describe each ECC key exchange algorithm |
94 | | -# in greater detail in terms of the content and processing of these |
95 | | -# messages. For ease of exposition, we defer discussion of client |
96 | | -# authentication and associated messages (identified with a + in |
97 | | -# Figure 1) until Section 3 and of the optional ECC-specific extensions |
98 | | -# (which impact the Hello messages) until Section 4. |
| 5 | +# This document introduces five new ECC-based key exchange algorithms |
| 6 | +# for TLS. All of them use ECDH to compute the TLS premaster secret, |
| 7 | +# and they differ only in the lifetime of ECDH keys (long-term or |
| 8 | +# ephemeral) and the mechanism (if any) used to authenticate them. The |
| 9 | +# derivation of the TLS master secret from the premaster secret and the |
| 10 | +# subsequent generation of bulk encryption/MAC keys and initialization |
| 11 | +# vectors is independent of the key exchange algorithm and not impacted |
| 12 | +# by the introduction of ECC. |
| 13 | +# |
| 14 | +# The table below summarizes the new key exchange algorithms, which |
| 15 | +# mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2] and |
| 16 | +# [3]), respectively. |
| 17 | +# |
| 18 | +# Key |
| 19 | +# Exchange |
| 20 | +# Algorithm Description |
| 21 | +# --------- ----------- |
| 22 | +# |
| 23 | +# ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. |
| 24 | +# |
| 25 | +# ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. |
| 26 | +# |
| 27 | +# ECDH_RSA Fixed ECDH with RSA-signed certificates. |
| 28 | +# |
| 29 | +# ECDHE_RSA Ephemeral ECDH with RSA signatures. |
| 30 | +# |
| 31 | +# ECDH_anon Anonymous ECDH, no signatures. |
| 32 | +# |
| 33 | +# Table 2: ECC Key Exchange Algorithms |
| 34 | +# |
| 35 | +# The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward |
| 36 | +# secrecy. With ECDHE_RSA, a server can reuse its existing RSA |
| 37 | +# certificate and easily comply with a constrained client's elliptic |
| 38 | +# curve preferences (see Section 4). However, the computational cost |
| 39 | +# |
| 40 | +# incurred by a server is higher for ECDHE_RSA than for the traditional |
| 41 | +# RSA key exchange, which does not provide forward secrecy. |
| 42 | +# |
| 43 | +# The ECDH_RSA mechanism requires a server to acquire an ECC |
| 44 | +# certificate, but the certificate issuer can still use an existing RSA |
| 45 | +# key for signing. This eliminates the need to update the keys of |
| 46 | +# trusted certification authorities accepted by TLS clients. The |
| 47 | +# ECDH_ECDSA mechanism requires ECC keys for the server as well as the |
| 48 | +# certification authority and is best suited for constrained devices |
| 49 | +# unable to support RSA. |
| 50 | +# |
| 51 | +# The anonymous key exchange algorithm does not provide authentication |
| 52 | +# of the server or the client. Like other anonymous TLS key exchanges, |
| 53 | +# it is subject to man-in-the-middle attacks. Implementations of this |
| 54 | +# algorithm SHOULD provide authentication by other means. |
| 55 | +# |
| 56 | +# Note that there is no structural difference between ECDH and ECDSA |
| 57 | +# keys. A certificate issuer may use X.509 v3 keyUsage and |
| 58 | +# extendedKeyUsage extensions to restrict the use of an ECC public key |
| 59 | +# to certain computations [15]. This document refers to an ECC key as |
| 60 | +# ECDH-capable if its use in ECDH is permitted. ECDSA-capable is |
| 61 | +# defined similarly. |
| 62 | +# |
| 63 | +# Client Server |
| 64 | +# ------ ------ |
| 65 | +# |
| 66 | +# ClientHello --------> |
| 67 | +# ServerHello |
| 68 | +# Certificate* |
| 69 | +# ServerKeyExchange* |
| 70 | +# CertificateRequest*+ |
| 71 | +# <-------- ServerHelloDone |
| 72 | +# Certificate*+ |
| 73 | +# ClientKeyExchange |
| 74 | +# CertificateVerify*+ |
| 75 | +# [ChangeCipherSpec] |
| 76 | +# Finished --------> |
| 77 | +# [ChangeCipherSpec] |
| 78 | +# <-------- Finished |
| 79 | +# |
| 80 | +# Application Data <-------> Application Data |
| 81 | +# |
| 82 | +# * message is not sent under some conditions |
| 83 | +# + message is not sent unless client authentication |
| 84 | +# is desired |
| 85 | +# |
| 86 | +# Figure 1: Message flow in a full TLS handshake |
| 87 | +# |
| 88 | +# Figure 1 shows all messages involved in the TLS key establishment |
| 89 | +# protocol (aka full handshake). The addition of ECC has direct impact |
| 90 | +# only on the ClientHello, the ServerHello, the server's Certificate |
| 91 | +# message, the ServerKeyExchange, the ClientKeyExchange, the |
| 92 | +# CertificateRequest, the client's Certificate message, and the |
| 93 | +# CertificateVerify. Next, we describe each ECC key exchange algorithm |
| 94 | +# in greater detail in terms of the content and processing of these |
| 95 | +# messages. For ease of exposition, we defer discussion of client |
| 96 | +# authentication and associated messages (identified with a + in |
| 97 | +# Figure 1) until Section 3 and of the optional ECC-specific extensions |
| 98 | +# (which impact the Hello messages) until Section 4. |
99 | 99 |
|
100 | 100 | [[spec]] |
101 | 101 | level = "SHOULD" |
|
0 commit comments