[Cfrg] My comments on TLS requirements from today's interim

Eric Rescorla <ekr@rtfm.com> Tue, 29 April 2014 19:51 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB4F1A09CE for <cfrg@ietfa.amsl.com>; Tue, 29 Apr 2014 12:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmiI07AlyN8z for <cfrg@ietfa.amsl.com>; Tue, 29 Apr 2014 12:51:27 -0700 (PDT)
Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id E28C51A094C for <cfrg@irtf.org>; Tue, 29 Apr 2014 12:51:26 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id w61so721207wes.1 for <cfrg@irtf.org>; Tue, 29 Apr 2014 12:51:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=9IjsfLLPk46ncI05YFNgP2Ha4v4iJQSZGLisIsG1Bzo=; b=DjIBkB4j+ahbg+w1L+vSZlhCs8HZR8NbIcTwpyHpvqK/jBIL6rrC9q70FpACD/M8RW P5fWrAO3AQcvyRp898Z1sRHk1miiRlCxd8Hsy1iEw5MlFtYDLf0A3HkV/mSNGiYFvc+C 9CoDtP+A+D//gcVs5JBiKLe82XChxemwxnyfoBhO8acjdwS6lsAB3b60J9knlm3wHUlP hPhy2tXbW7cEXdRzDw9tuPh+qyQnd6BQu2W844hYaWaqYSrtgX4chVCKPfiRa1FijeAr 0yOePvApKjE5RuDJhGD8Rk/3/DROfV7GWm63eV9Yrb3UOsYfjWbPm+lHj3raP/K/kgKz 5N2Q==
X-Gm-Message-State: ALoCoQlehT6I3nQ84ZrlY9vKo9jwlI7Ri5mq3N+5W4QB1FPHO7P7/+gYza7rMhGPpj7PqVTcLTLY
X-Received: by 10.181.8.204 with SMTP id dm12mr2042591wid.1.1398801085302; Tue, 29 Apr 2014 12:51:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Tue, 29 Apr 2014 12:50:45 -0700 (PDT)
X-Originating-IP: [63.245.219.54]
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 29 Apr 2014 12:50:45 -0700
Message-ID: <CABcZeBOMUw5fv--ar=r+5KL76UKz7NDU2M=aEYomjfMjSy+Fog@mail.gmail.com>
To: cfrg <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="001a113484cacd266304f833c117"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/G3BaQ5LrhS3Hz6psGL95fQPJ37w
Subject: [Cfrg] My comments on TLS requirements from today's interim
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Apr 2014 19:51:29 -0000

Here's what I think would best benefit TLS as an output of this curve
selection
process:

- An IETF-wide set of curves so we can share them with IPsec, SSH, etc.

- A single curve/set of curves at each security level for each application.
  I say a set of curves because it may be the case that you have one curve
  for signature and one for key agreement, but you shouldn't have,
  say, four curves used for key agreement at the 256-bit level. [0]

- Minimally cover the 256- and 512-bit security levels. I think 384 would
  be fine if there was a strong reason, but it's probably not necessary.

- It would be nice if there was some chance that these curves could
  have some chance of being FIPS-approved, so they could potentially
  displace the NIST curves. It may be very difficult to get certainty here.

This obviously isn't an exclusive list of desiderata, but I wanted to avoid
duplication with David's otherwise quite nice list.

-Ekr