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

Nico Williams <> Fri, 01 November 2013 23:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D557E11E817D for <>; Fri, 1 Nov 2013 16:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oUw0HgavDRdp for <>; Fri, 1 Nov 2013 16:40:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EBCAE11E8136 for <>; Fri, 1 Nov 2013 16:40:34 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 5FE432005D105; Fri, 1 Nov 2013 16:40:34 -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=m9Ot+IpRn81TFz BJzNlSes5S/As=; b=AdE/8rqiTVW6IQ4FjL3kk/8X0iXZuPHs4UeFkroEZSHccB wKK305iOk66tnLyP8npruNvuafZoXu09oiMEitCyZRQ50a5YAwWdVz5N8WZeAK0W C3OWYtcLzar+THyv75L/XmjPKtkxxkmwfIRUhosTGK4Ub56NEDG6cop972Y3w=
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 043A62005D104; Fri, 1 Nov 2013 16:40:33 -0700 (PDT)
Date: Fri, 1 Nov 2013 18:40:31 -0500
From: Nico Williams <>
To: Robert Ransom <>
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: Fri, 01 Nov 2013 23:40:40 -0000

On Fri, Nov 01, 2013 at 04:34:24PM -0700, Robert Ransom wrote:
> The server should be allowed to send up to 32 bytes of nonce.  Some
> servers will want to conceal the lifetime of their keypair by
> generating nonces using a counter encrypted or hashed with a secret,
> using the cheapest encryption or hash function available; this may be
> TEA, AES, SHA-256, or something else, depending on the hardware.  Some
> servers will want to use a fast RNG to generate nonces.  32 bytes
> should be enough to prevent even a random (or hash-derived) nonce from
> repeating; anything less than that may not be enough for some servers.

The point of smaller/fewer nonces is two-fold:

 - if anyone was using 32 bytes of Dual_EC DRBG output before and it
   went unnoticed because, hey, that's what it's there fore, well, now
   it may be more noticeable if they do that sort of thing and spread
   those magic 32 bytes over several nonces

   Yes, this is fighting yesterday's war.  But anyways.

 - less subliminal channel bandwidth (same thing)

   Subliminal channels are very difficult to eliminate.  Merely reducing
   their bandwidth ought to help.  If, for example, there's only a 16
   bytes total of nonces in the handshakes (8 bytes for each of the
   client and server), and the cipher+mode in use doesn't need random
   IVs, then TLS connections would have no subliminal channels
   post-handshake, and hopefully the channel in the handshakes is very
   small (there's still bogus extensions and such to consider, but those
   at least can stand out).

   Worth it?  I think so.