Network Working Group B. Black
Internet-Draft Microsoft
Intended status: Informational T. Acar
Expires: January 4, 2015 Microsoft Research
M. Ray
Microsoft
July 3, 2014

Nothing Up My Sleeve (NUMS) Curves for Ephemeral Key Exchange in Transport Layer Security (TLS)
draft-black-tls-numscurves-00

Abstract

This document specifies the use of the Nothing Up My Sleeve (NUMS) twisted Edwards curves at the 128 and 256-bit security levels for ephemeral key exchange in Transport Layer Security (TLS).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 4, 2015.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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

1. Introduction

In [NUMS] a family of deterministically generated Nothing Up My Sleeve (NUMS) elliptic curves over prime fields was specified based on [MSRECC]. These curves support constant-time, exception-free scalar multiplications that are resistant to a wide range of side-channel attacks including timing and cache attacks, thereby offering high practical security in cryptographic applications.

Their negotiation for key exchange according to [RFC4492] requires the definition and assignment of additional NamedCurve identifiers. This document specifies values for two twisted Edwards curves from [NUMS].

1.1. Requirements Language

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 [RFC2119].

2. NUMS NamedCurve Types

As defined in [RFC4492], the name space NamedCurve is used for the negotiation of elliptic curve groups for key exchange during TLS session establishment. This document adds new NamedCurve types for two of the elliptic curves defined in [NUMS] as follows:

      enum {
          numsp256t1(TBD1),
          numsp512t1(TBD2)
      } NamedCurve;

These curves are suitable for use with Datagram TLS [RFC6347].

3. Contributors
Joppe W. Bos NXP Semiconductors
Craig Costello Microsoft Research
Brian LaMacchia Microsoft Research
Patrick Longa Microsoft Research
Michael Naehrig Microsoft Research

4. IANA Considerations

IANA is requested to assign numbers for the curves listed in Section 2 in the "EC Named Curve" [IANA-TLS] registry of the "Transport Layer Security (TLS) Parameters" registry as follows:

Value Description DTLS-OK Reference
TBD1 numsp256t1 Y this doc
TBD2 numsp512t1 Y this doc

5. Security Considerations

This memo is entirely concerned with security, but there are specific considerations for implementations of the NUMS curves in TLS.

  1. The security consideration in [RFC4492] and [RFC5246] for TLS handshakes using the ECC ciphersuites are applicable to the use of curves in this memo.
  2. All the security considerations of the underlying NUMS curves and their implementations apply. A comprehensive treatment is in [NUMS] and [MSRECC].
  3. The PFS (Perfect Forward Secrecy) provided by ECDHE in TLS is bounded by the duration of the session secrets stored on the peers (client and server), including caches, e.g., memory and disk caches. Implementations must especially pay attention to the session ticket cache on the server, as the security of the connection is limited by the security of this cache. A detailed treatment of PFS implementation issues is given in [BOTCH].
  4. We also refer readers to [THS] for triple handshake authentication attacks that exploit RSA and DH key exchange combinations. For instance, most ECDHE implementations accept named curves from a known set whereas DHE implementations accept explicit DH parameters from the server. While named curves provide protection against triple handshake attacks, if the cipher suites in this draft are used with explicit ECC parameters, the same attacks might apply.
  5. Implementations must prevent against cross-protocol attacks where an adversary may deceive a client to interpret ECDH[E] ServerKeyExchange messages as RSA or DH[E] ServerKeyExchange messages (and vice versa), and, in general, any message other than the intended ECDH[E] messages. We refer the reader to Wagner/Schneier and related cross protocol attacks detailed in [XPA].

6. References

6.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

6.2. Informative References

[BOTCH] Langley, A., "", June 2013.
[MSRECC] Bos, J., Costello, C., Longa, P. and M. Naehrig, "Selecting Elliptic Curves for Cryptography: An Efficiency and Security Analysis", February 2014.
[NUMS] Black, B., Bos, J., Costello, C., Longa, P. and M. Naehrig, "Elliptic Curve Cryptography (ECC) Nothing Up My Sleeve (NUMS) Curves and Curve Generation", June 2014.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C. and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[THS] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A. and P. Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS", May 2014.
[XPA] Mavrogiannopoulos, N., Vercauteren, F., Velichkov, V. and B. Preneel, "A Cross-Protocol Attack on the TLS Protocol", October 2012.

Appendix A. Test Vectors

This section provides test vectors for example Diffie-Hellman key exchanges using the curves numsp256t1 and numsp512t1. The following notation is used:

  s_A: the secret key of party A

  x_A: the x-coordinate of the public key of party A

  y_A: the y-coordinate of the public key of party A

  s_B: the secret key of party B

  x_B: the x-coordinate of the public key of party B

  y_B: the y-coordinate of the public key of party B

  x_SS: the x-coordinate of the Diffie-Hellman shared secret

  y_SS: the y-coordinate of the Diffie-Hellman shared secret

A.1. 256-Bit Curve

Curve numsp256t1

  s_A =
  0x22A13B32B730C46BD0664044F2144FADDC497D9EF6324912FD367840EE509A20

  x_A =
  0x4E911BB0A5F4F850D8C61F1A87A4D7E689713597CA8740320D0F9B4AF4CE5D4D

  y_A =
  0x3F9ED46B9C702B3B7C267A79C1C75B02ADFF274919B708F094A1088762ED71CD

  s_B =
  0x1667BF53CCC9EAB280E9D599C57E802D0E5D82A890A5958228F6A0946A2904EF

  x_B =
  0x9FD536B5B8CFB1FDE0C4ACBDC57041CF4BE97501ADACAEBF284884ECF9D4CF40

  y_B =
  0x5A9046F9BB6F35D2F1A8C9835415793056596449D5CC93CFFB8C3C89EF127928

  x_SS =
  0x5967C998CF694C90BB1869886B6A07EC772760978E94B8EE873906A75DE323E6

  y_SS =
  0x53603A22E48B10054B53CB3F13E8412C36B60C66CBB673C60215DC79B72C1900

A.2. 512-Bit Curve

Curve numsp512t1

  s_A =
  0x1667BF53CCC9EAB280E9D599C57E802C499D72B90299CAB0DA1F8BE19D9122F7
   2AF22314E7A0913EDDF8D75724547DDB458A5DCC93B21A7711CC02DFCC339585

  x_A =
  0xE105BDAC3E5EFF691B098F605960DD11BFF50B6C27FEAC359077E140098BFFA6
   8EA799DE43F521A09FC98A22D1A349CBB7E5F1BEC18A49494FD103C2BF44F55D

  y_A =
  0xD8AED3EA0734C996BDC469BBB7D71B2A554C5E88C0639FE7432F9CE7C57D6527
   9BD491A4C1B43B7044CD3ABBF393E16FB47D62A8114A8DF2D31A7DA60F26F2A1

  s_B =
  0x2D90D3CFCCF42232CF357E59A4D49FD4D5F40C9E74331E12C9CB532C39E8D702
   774A4F84F01DE67272169C9D1ED1CD618F69FF614957EF83668EDC2D7ED614BF

  x_B =
  0x606A43D636D365D56B3D5F0CE7A21F862492C89C3F22C167B695E322E3CC56EA
   E990AFEC979236FF14262A45AA8C856C52611B0DF98BF896AA69FFE9276F6399

  y_B =
  0xEE727A35113D4975F9FC87D477CF443CAFFC333418DA3BB1AD3D787C48C43CE5
   50E27CF616F5BEAF2C68103CB1D812086329C10F1DD988111A79F6FBAE77CD24

  x_SS =
  0x29E1C3540417274BE35F3231BC4F6FC41E7424F0CAA6BA79219E1C7D2695115D
   08C9AC7EC94ECB6EDB7DFDCB2FF3A0976C23442B64BDE725752D4C77AE83430F

  y_SS =
  0x9FAD25F2E31AF9348258E7C036DA873B6D7B41AC0BFB0D4522339DEB591BB98A
   2498C928EF4A379052E6547BC94AB26FEBDD0E76DCD409A45A31505654687AFF

Authors' Addresses

Benjamin Black Microsoft One Microsoft Way Redmond, WA 98115 US EMail: benblack@microsoft.com
Tolga Acar Microsoft Research One Microsoft Way Redmond, WA 98115 US EMail: tolga@microsoft.com
Marsh Ray Microsoft One Microsoft Way Redmond, WA 98115 US EMail: maray@microsoft.com