1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
|
<pre>Internet Engineering Task Force (IETF) D. McGrew
Request for Comments: 7251 Cisco Systems
Category: Informational D. Bailey
ISSN: 2070-1721 Ruhr-University Bochum
M. Campagna
R. Dugal
Certicom Corp.
June 2014
<span class="h1">AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS</span>
Abstract
This memo describes the use of the Advanced Encryption Standard (AES)
in the Counter and CBC-MAC Mode (CCM) of operation within Transport
Layer Security (TLS) to provide confidentiality and data-origin
authentication. The AES-CCM algorithm is amenable to compact
implementations, making it suitable for constrained environments,
while at the same time providing a high level of security. The
cipher suites defined in this document use Elliptic Curve
Cryptography (ECC) and are advantageous in networks with limited
bandwidth.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7251">http://www.rfc-editor.org/info/rfc7251</a>.
<span class="grey">McGrew, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7251">RFC 7251</a> AES-CCM ECC TLS June 2014</span>
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Conventions Used in This Document . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. ECC-Based AES-CCM Cipher Suites . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. Requirements on Curves and Hashes . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3">3</a>. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.2">5.2</a>. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.3">5.3</a>. Hardware Security Modules . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-6">6</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-7">7</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-7.1">7.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-7.2">7.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#appendix-A">Appendix A</a>. Recommended Curves and Algorithms . . . . . . . . . <a href="#page-9">9</a>
<span class="grey">McGrew, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7251">RFC 7251</a> AES-CCM ECC TLS June 2014</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document describes the use of Advanced Encryption Standard (AES)
[<a href="#ref-AES" title=""Specification for the Advanced Encryption Standard (AES)"">AES</a>] in Counter with CBC-MAC Mode (CCM) [<a href="#ref-CCM" title=""Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality"">CCM</a>] in several TLS cipher
suites. AES-CCM provides both authentication and confidentiality
(encryption and decryption) and uses as its only primitive the AES
encrypt block cipher operation. This makes it amenable to compact
implementations, which are advantageous in constrained environments.
Of course, adoption outside of constrained environments is necessary
to enable interoperability, such as that between web clients and
embedded servers, or between embedded clients and web servers. The
use of AES-CCM has been specified for the IPsec Encapsulating
Security Payload (ESP) [<a href="./rfc4309" title=""Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)"">RFC4309</a>] and 802.15.4 wireless networks
[<a href="#ref-IEEE802154">IEEE802154</a>].
Authenticated encryption, in addition to providing confidentiality
for the plaintext that is encrypted, provides a way to check its
integrity and authenticity. Authenticated Encryption with Associated
Data, or AEAD [<a href="./rfc5116" title=""An Interface and Algorithms for Authenticated Encryption"">RFC5116</a>], adds the ability to check the integrity and
authenticity of some associated data that is not encrypted. This
memo utilizes the AEAD facility within TLS 1.2 [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] and the AES-
CCM-based AEAD algorithms defined in [<a href="./rfc5116" title=""An Interface and Algorithms for Authenticated Encryption"">RFC5116</a>] and [<a href="./rfc6655" title=""AES-CCM Cipher Suites for Transport Layer Security (TLS)"">RFC6655</a>]. All of
these algorithms use AES-CCM; some have shorter authentication tags
and are therefore more suitable for use across networks in which
bandwidth is constrained and message sizes may be small.
The cipher suites defined in this document use Ephemeral Elliptic
Curve Diffie-Hellman (ECDHE) as their key establishment mechanism;
these cipher suites can be used with DTLS [<a href="./rfc6347" title=""Datagram Transport Layer Security Version 1.2"">RFC6347</a>].
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Conventions Used in This Document</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. ECC-Based AES-CCM Cipher Suites</span>
The cipher suites defined in this document are based on the AES-CCM
Authenticated Encryption with Associated Data (AEAD) algorithms
AEAD_AES_128_CCM and AEAD_AES_256_CCM described in [<a href="./rfc5116" title=""An Interface and Algorithms for Authenticated Encryption"">RFC5116</a>]. The
following cipher suites are defined:
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM = {0xC0,0xAC}
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CCM = {0xC0,0xAD}
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 = {0xC0,0xAE}
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 = {0xC0,0xAF}
<span class="grey">McGrew, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7251">RFC 7251</a> AES-CCM ECC TLS June 2014</span>
These cipher suites make use of the AEAD capability in TLS 1.2
[<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>]. Note that each of these AEAD algorithms uses AES-CCM.
Cipher suites ending with "8" use eight-octet authentication tags;
the other cipher suites have 16-octet authentication tags.
The HMAC truncation option described in <a href="./rfc6066#section-7">Section 7 of [RFC6066]</a> (which
negotiates the "truncated_hmac" TLS extension) does not have an
effect on the cipher suites defined in this note, because they do not
use HMAC to protect TLS records.
The "nonce" input to the AEAD algorithm is as defined in [<a href="./rfc6655" title=""AES-CCM Cipher Suites for Transport Layer Security (TLS)"">RFC6655</a>].
In DTLS, the 64-bit seq_num field is the 16-bit DTLS epoch field
concatenated with the 48-bit sequence_number field. The epoch and
sequence_number appear in the DTLS record layer.
This construction allows the internal counter to be 32 bits long,
which is a convenient size for use with CCM.
These cipher suites make use of the default TLS 1.2 Pseudorandom
Function (PRF), which uses HMAC with the SHA-256 hash function.
The ECDHE_ECDSA key exchange is performed as defined in [<a href="./rfc4492" title=""Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)"">RFC4492</a>],
with the following additional stipulations:
o Curves with a cofactor equal to one SHOULD be used; this
simplifies their use.
o The uncompressed point format MUST be supported. Other point
formats MAY be used.
o The client SHOULD offer the elliptic_curves extension, and the
server SHOULD expect to receive it.
o The client MAY offer the ec_point_formats extension, but the
server need not expect to receive it.
o Fundamental ECC algorithms [<a href="./rfc6090" title=""Fundamental Elliptic Curve Cryptography Algorithms"">RFC6090</a>] MAY be used as an
implementation method.
o If the server uses a certificate, then the requirements in <a href="./rfc4492">RFC</a>
<a href="./rfc4492">4492</a> apply: "The server's certificate MUST contain an ECDSA-
capable public key and be signed with ECDSA." Guidance on
acceptable choices of hashes and curves that can be used with each
cipher suite is detailed in <a href="#section-2.2">Section 2.2</a>. The Signature Algorithms
extension (<a href="./rfc5246#section-7.4.1.4.1">Section 7.4.1.4.1 of [RFC5246]</a>) SHOULD be used to
indicate support of those signature and hash algorithms. If a
client certificate is used, the same criteria SHOULD apply to it.
<span class="grey">McGrew, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7251">RFC 7251</a> AES-CCM ECC TLS June 2014</span>
Implementations of these cipher suites will interoperate with
[<a href="./rfc4492" title=""Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)"">RFC4492</a>] but can be more compact than a full implementation of that
RFC.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. AEAD Algorithms</span>
The following AEAD algorithms are used:
AEAD_AES_128_CCM is used in the TLS_ECDHE_ECDSA_WITH_AES_128_CCM
cipher suite,
AEAD_AES_256_CCM is used in the TLS_ECDHE_ECDSA_WITH_AES_256_CCM
cipher suite,
AEAD_AES_128_CCM_8 is used in the
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite, and
AEAD_AES_256_CCM_8 is used in the
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 cipher suite.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Requirements on Curves and Hashes</span>
Implementations SHOULD select elliptic curves and hash functions so
that AES-128 is used with a curve and a hash function supporting a
128-bit security level, and AES-256 is used with a curve and a hash
function supporting a 192-bit or 256-bit security level. More
detailed guidance on cryptographic parameter selection is given in
[<a href="#ref-SP800-57" title=""Recommendation for Key Management - Part 1: General (Revision 3)"">SP800-57</a>] (see especially Tables 2 and 3).
<a href="#appendix-A">Appendix A</a> describes suitable curves and hash functions that are
widely available.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. TLS Versions</span>
These cipher suites make use of the authenticated encryption with
additional data defined in TLS 1.2 [<a href="./rfc5288" title=""AES Galois Counter Mode (GCM) Cipher Suites for TLS"">RFC5288</a>]. They MUST NOT be
negotiated in older versions of TLS. Clients MUST NOT offer these
cipher suites if they do not offer TLS 1.2 or later. Servers that
select an earlier version of TLS MUST NOT select one of these cipher
suites. Earlier versions do not have support for AEAD; for instance,
the TLSCiphertext structure does not have the "aead" option in TLS
1.1. Because TLS has no way for the client to indicate that it
supports TLS 1.2 but not earlier versions, a non-compliant server
might potentially negotiate TLS 1.1 or earlier and select one of the
cipher suites in this document. Clients MUST check the TLS version
and generate a fatal "illegal_parameter" alert if they detect an
incorrect version.
<span class="grey">McGrew, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7251">RFC 7251</a> AES-CCM ECC TLS June 2014</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
IANA has assigned the values for the cipher suites defined in
<a href="#section-2">Section 2</a> from the "TLS Cipher Suite Registry". The DTLS-OK column
has been marked as "Y" for each of these algorithms.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Perfect Forward Secrecy</span>
The perfect forward secrecy properties of ephemeral Diffie-Hellman
cipher suites are discussed in the security analysis of [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>].
This analysis applies to the ECDHE cipher suites.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Counter Reuse</span>
AES-CCM security requires that the counter never be reused. The IV
construction in <a href="#section-2">Section 2</a> is designed to prevent counter reuse.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Hardware Security Modules</span>
A cipher suite can be implemented in such a way that the secret keys
and private keys are stored inside a Hardware Security Module (HSM),
and the cryptographic operations involving those keys are performed
by the HSM on data provided by an application interacting with the
HSM through an interface such as that defined by the Cryptographic
Token Interface Standard [<a href="#ref-PKCS11" title=""PKCS #11: Cryptographic Token Interface Standard version 2.20"">PKCS11</a>]. When an AEAD cipher suite, such
as those in this note, are implemented in this way, special handling
of the nonce is required. This is because the "salt" part of the
nonce is set to the client_write_IV or server_write_IV, which is a
function of the TLS master secret.
Another potential issue with the Cryptographic Token Interface
Standard is that the use of the DecryptUpdate function is not
possible with the CCM decrypt operation or the decrypt operation of
any other authenticated encryption method. This is because the
DecryptUpdate requires that post-decryption plaintext be returned
before the authentication check is completed.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Acknowledgements</span>
This document borrows heavily from [<a href="./rfc5288" title=""AES Galois Counter Mode (GCM) Cipher Suites for TLS"">RFC5288</a>]. Thanks are due to
Robert Cragie for his great help in making this work complete,
correct, and useful, and to Peter Dettman for his review. Thanks
also to Mike StJohns for pointing out the HSM issues.
This document is motivated by the considerations raised in the Zigbee
Smart Energy 2.0 working group.
<span class="grey">McGrew, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7251">RFC 7251</a> AES-CCM ECC TLS June 2014</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-AES">AES</a>] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard
(AES)", FIPS 197, November 2001.
[<a id="ref-CCM">CCM</a>] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation: The
CCM Mode for Authentication and Confidentiality", SP
800-38C, May 2004.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC4492">RFC4492</a>] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", <a href="./rfc4492">RFC 4492</a>, May 2006.
[<a id="ref-RFC5116">RFC5116</a>] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", <a href="./rfc5116">RFC 5116</a>, January 2008.
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>, August 2008.
[<a id="ref-RFC5288">RFC5288</a>] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", <a href="./rfc5288">RFC 5288</a>,
August 2008.
[<a id="ref-RFC5639">RFC5639</a>] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography
(ECC) Brainpool Standard Curves and Curve Generation", <a href="./rfc5639">RFC</a>
<a href="./rfc5639">5639</a>, March 2010.
[<a id="ref-RFC6066">RFC6066</a>] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", <a href="./rfc6066">RFC 6066</a>, January 2011.
[<a id="ref-RFC6090">RFC6090</a>] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", <a href="./rfc6090">RFC 6090</a>, February 2011.
[<a id="ref-RFC6347">RFC6347</a>] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", <a href="./rfc6347">RFC 6347</a>, January 2012.
[<a id="ref-RFC6655">RFC6655</a>] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
Transport Layer Security (TLS)", <a href="./rfc6655">RFC 6655</a>, July 2012.
<span class="grey">McGrew, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7251">RFC 7251</a> AES-CCM ECC TLS June 2014</span>
[<a id="ref-SP800-57">SP800-57</a>] National Institute of Standards and Technology,
"Recommendation for Key Management - Part 1: General
(Revision 3)", SP 800-57 Part 1, July 2012.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-IEEE802154">IEEE802154</a>]
IEEE, "Wireless Personal Area Networks", IEEE Standard
802.15.4-2006, 2006.
[<a id="ref-PKCS11">PKCS11</a>] RSA Laboratories, "PKCS #11: Cryptographic Token Interface
Standard version 2.20", Public Key Cryptography Standards
PKCS#11-v2.20, 2004.
[<a id="ref-RFC4309">RFC4309</a>] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", <a href="./rfc4309">RFC</a>
<a href="./rfc4309">4309</a>, December 2005.
<span class="grey">McGrew, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7251">RFC 7251</a> AES-CCM ECC TLS June 2014</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Recommended Curves and Algorithms</span>
This memo does not mandate any particular elliptic curves or
cryptographic algorithms, for the sake of flexibility. However,
since the main motivation for the AES-CCM-ECC cipher suites is their
suitability for constrained environments, it is valuable to identify
a particular suitable set of curves and algorithms.
This appendix identifies a set of elliptic curves and cryptographic
algorithms that meet the requirements of this note and that are
widely supported and believed to be secure.
The curves and hash algorithms recommended for each cipher suite are:
An implementation that includes either
TLS_ECDHE_ECDSA_WITH_AES_128_CCM or
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 SHOULD support the secp256r1
curve and the SHA-256 hash function.
An implementation that includes either
TLS_ECDHE_ECDSA_WITH_AES_256_CCM or
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 SHOULD support the secp384r1
curve and the SHA-384 hash function, and MAY support the secp521r1
curve and the SHA-512 hash function.
More information about the secp256r1, secp384r1, and secp521r1 curves
is available in <a href="./rfc4492#appendix-A">Appendix A of [RFC4492]</a>.
It is not necessary to implement the above curves and hash functions
in order to conform to this specification. Other elliptic curves,
such as the Brainpool curves [<a href="./rfc5639" title=""Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation"">RFC5639</a>], for example, meet the
criteria laid out in this memo.
<span class="grey">McGrew, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7251">RFC 7251</a> AES-CCM ECC TLS June 2014</span>
Authors' Addresses
David McGrew
Cisco Systems
13600 Dulles Technology Drive
Herndon, VA 20171
USA
EMail: mcgrew@cisco.com
Daniel V. Bailey
Ruhr-University Bochum
Universitatsstr. 150
44801 Bochum
Germany
EMail: danbailey@sth.rub.de
Matthew Campagna
Certicom Corp.
5520 Explorer Drive #400
Mississauga, Ontario L4W 5L1
Canada
EMail: mcampagna@gmail.com
Robert Dugal
Certicom Corp.
4701 Tahoe Blvd., Building A
Mississauga, Ontario L4W 0B5
Canada
EMail: rdugal@certicom.com
McGrew, et al. Informational [Page 10]
</pre>
|
