Re: [TLS] What would make TLS cryptographically better for TLS 1.3

Nico Williams <> Thu, 31 October 2013 23:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1E2D21F9DFC for <>; Thu, 31 Oct 2013 16:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.286
X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mKB8WvSGmHFG for <>; Thu, 31 Oct 2013 16:10:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 665E021F9F74 for <>; Thu, 31 Oct 2013 16:10:04 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 2D407678063; Thu, 31 Oct 2013 16:10:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=gKKLqQ+8NFbs9p 956Lc24amEGGA=; b=wO1LbX9BjVSzD3h7lEu8zQr0/qLVizoMFvXhqCpJq8jMBt mwhru6c97Nw1F3LhmiAefxS/owUXNhEmOxPCxhdQxnPHjg5XSG+1zQgd3TsTAUve uoyxAzvozMiW4/BNsDCu7vKjfNfr0Lo2NIyuraO7SThNWEifJu1EEUBfozTlE=
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 96C71678062; Thu, 31 Oct 2013 16:10:02 -0700 (PDT)
Date: Thu, 31 Oct 2013 18:09:59 -0500
From: Nico Williams <>
To: Watson Ladd <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "" <>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Oct 2013 23:10:09 -0000

My list:

 - It should be deployable, that's first; in particular, it needs to be
   deployable with ECDH PFS key exchanges.

   This means that the mess of *DHE* ciphersuite and group/curve
   negotiation urgently needs a revamp.  We need to de-explode the
   cipher suite registry by separating negotiation of key exchange, KDF,
   and server authentication algorithms/methods from each other and from
   the symmetric cipher/modes.  This should have the bonus of yielding
   smaller hello messages (except during the transition to 1.3, natch).

 - It needs to use modern cipher modes for AES and friends: GCM, CCM,
   and *maybe* an option for AEAD by generic composition (AES-CBC-SHA3
   or AES-CBC-HMAC-SHA256, encrypt-then-mac, ... with random IV

 - Many fewer nonce bytes and random IVs where possible.  Nonce payloads
   should be sent when needed, if needed.  For example, to derive a
   session key from an DHE shared secret one does not really need
   nonces.  This means that counter modes are better, for example, than
   CBC modes.

   Perry Metzger recently proposed (I'm extrapolating a bit) a
   random-IV-free CBC-like cipher mode where instead of a nonce one
   sends a [small] counter which must be encryted to recover the IV
   for use as the first block in the CBC decryption of the ciphertext.
   I kinda like this.

   CBC has some advantages over counter modes.  However, for this
   particular application (TLS and DTLS) it's easy enough to avoid (and
   detect) counter reuse that counter modes' disadvantages are


 - Renegotiation should be replaced with an NPN-like extension that
   provides privacy to the TLS client principal name.

 - Design-in channel bindings from the get-go.