idnits 2.17.1 draft-josefsson-tls-eddsa2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 8, 2015) is 3244 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational draft: draft-josefsson-tls-curve25519 (ref. 'I-D.josefsson-tls-curve25519') == Outdated reference: A later version (-03) exists of draft-josefsson-eddsa-ed25519-02 ** Downref: Normative reference to an Informational draft: draft-josefsson-eddsa-ed25519 (ref. 'I-D.josefsson-eddsa-ed25519') Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Josefsson 3 Internet-Draft SJD AB 4 Intended status: Standards Track June 8, 2015 5 Expires: December 10, 2015 7 EdDSA and Ed25519 for Transport Layer Security (TLS) 8 draft-josefsson-tls-eddsa2-00 10 Abstract 12 This document introduce the public-key signature algorithm EdDSA for 13 use in Transport Layer Security (TLS). By using a new 14 SignatureAlgorithm value, defined in this document, together with the 15 NamedCurve and ECPointFormat assignments from the Curve25519 ECDHE 16 key exchange mechanism, we describe how EdDSA is used for digital 17 signatures in the existing ECDSA cipher suites. This is intended to 18 work with any version of TLS and Datagram TLS. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 10, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. Introduction 54 TLS [RFC5246] and DTLS [RFC6347] support different key exchange 55 algorithms and authentication mechanisms. In ECC in TLS [RFC4492], 56 key exchange and authentication using ECC is specified, where the 57 NamedCurve and ECPointFormat registries and associated TLS extensions 58 are introduced. 60 In [I-D.josefsson-tls-curve25519] support for ECDHE key exchange with 61 the Curve25519 curve is added. That document introduces a new 62 NamedCurve value for Curve25519, and a new ECPointFormat value to 63 correspond to the public-key encoding. 65 This document describes how to use EdDSA and Ed25519 66 [I-D.josefsson-eddsa-ed25519] as a new authentication mechanism in 67 TLS. It reuses the newly registered NamedCurve and ECPointFormat 68 values, and define a new SignatureAlgorithm value to indicate EdDSA. 70 The goal is that all existing ECDSA cipher suites will, when the 71 EdDSA SignatureAlgorithm is negotiated, use EdDSA instead of the 72 traditional ECDSA signature algorithm. 74 This document is a self-contained alternative to draft-josefsson-tls- 75 eddsa. This document reuse the ECDSA cipher suites for EdDSA, 76 whereas draft-josefsson-tls-eddsa specify new cipher suites for 77 EdDSA. It is an open issue which approach is to be prefered. 79 1.1. Requirements Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 2. EdDSA SignatureAlgorithm 87 Negotiation of the authentication mechanism is signalled by sending a 88 SignatureAlgorithm value. Here we extend this enumeration for EdDSA. 90 enum { 91 eddsa(4) 92 } SignatureAlgorithm; 94 EdDSA is suitable for use with TLS [RFC5246] and DTLS [RFC6347]. 96 3. Using EdDSA in a handshake 98 The following describe how EdDSA is used in a handshake. For ease of 99 explanation, we assume a full handshake. [RFC4492] describes the 100 semantics of ECC in TLS, including how resumed handshakes work, and 101 this document refer to it for a complete discussion. 103 A client that wish to negotiate use of EdDSA in a handshake MUST 104 offer a ECDSA key exchange algorithm and send, in the same way as is 105 done for other Signature Algorithms in ECDSA, a Signature Algorithm 106 extension that include the "eddsa" SignatureAlgorithm value 108 The HashAlgorithm value to specify for EdDSA MUST be "none" as the 109 EdDSA signature algorithm does not hash the input before signing. 111 The client MUST also include a Supported Elliptic Curves Extension 112 ("NamedCurve") containing the "Curve25519" value defined in 113 [I-D.josefsson-tls-curve25519]. This is used to indicate request for 114 Ed25519. Use of other curves with EdDSA is not defined here. 116 The client MUST also include a Supported Point Formats Extension 117 ("ECPointFormat") that contains the "montgomery_x_le" value defined 118 in [I-D.josefsson-tls-curve25519]. 120 This document RECOMMENDS use of ECDHE_ECDSA key exchange algorithm, 121 in particular with Curve25519, rather than the ECDH_ECDSA key 122 exchange algorithm. 124 4. IANA Considerations 126 EdDSA should be registered in the Transport Layer Security (TLS) 127 Parameters [IANA-TLS] registry under "SignatureAlgorithm" as follows. 129 +-------+-------------+---------+-----------+ 130 | Value | Description | DTLS-OK | Reference | 131 +-------+-------------+---------+-----------+ 132 | 4 | eddsa | Y | This doc | 133 +-------+-------------+---------+-----------+ 135 5. Security Considerations 137 The security considerations of TLS [RFC5246], DTLS [RFC6347], ECC in 138 TLS [RFC4492] Curve25519 in TLS [I-D.josefsson-tls-curve25519], and 139 EdDSA and Ed25519 [I-D.josefsson-eddsa-ed25519] are inherited. 141 As with all cryptographic algorithms, the reader should stay informed 142 about new research insights into the security of the algorithms 143 involved. 145 While discussed in the EdDSA/Ed25519 specification and papers, we 146 would like to stress the significance of secure implementation of 147 EdDSA/Ed25519. For example, implementations ought to be constant- 148 time to avoid side-channel attacks. 150 6. Acknowledgements 152 Thanks to Yoav Nir for suggesting re-use of ECDSA cipher suites with 153 EdDSA, to reduce the cartesian product cipher suite explosion. 154 Thanks to Klaus Hartke and Nicolas Williams for fixes to the 155 document. 157 7. References 159 7.1. Normative References 161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 162 Requirement Levels", BCP 14, RFC 2119, March 1997. 164 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 165 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 166 for Transport Layer Security (TLS)", RFC 4492, May 2006. 168 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 169 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 171 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 172 Security Version 1.2", RFC 6347, January 2012. 174 [I-D.josefsson-tls-curve25519] 175 Josefsson, S. and M. Pegourie-Gonnard, "Curve25519 for 176 ephemeral key exchange in Transport Layer Security (TLS)", 177 draft-josefsson-tls-curve25519-06 (work in progress), 178 September 2014. 180 [I-D.josefsson-eddsa-ed25519] 181 Josefsson, S. and N. Moller, "EdDSA and Ed25519", draft- 182 josefsson-eddsa-ed25519-02 (work in progress), February 183 2015. 185 7.2. Informative References 187 [IANA-TLS] 188 Internet Assigned Numbers Authority, "Transport Layer 189 Security (TLS) Parameters", 190 . 193 Author's Address 195 Simon Josefsson 196 SJD AB 198 Email: simon@josefsson.org