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

Nico Williams <> Sat, 02 November 2013 21:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2700A11E8241 for <>; Sat, 2 Nov 2013 14:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.184
X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lULRPpCpQrav for <>; Sat, 2 Nov 2013 14:14:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ED79011E811D for <>; Sat, 2 Nov 2013 14:14:58 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 70CD2286059; Sat, 2 Nov 2013 14:14:58 -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=uccQbX9KdEiYM4 LYefiZZvxEoyo=; b=ZTrQm8qh95CgF/M96xNSSd3CoRonxxQcL2fA/wcMNZaCZH PT+oer0ASO90EvwOrM4AU9PIl5xAPSD2Jnt15VRNIeE3LKy1vy3pOnQM6IS39RSa 7VeEmFfM1zPwH3WLtYvyWr0jtu7LJIxz76xqA0iS++7F5Va60TFDt5FHhfyz0=
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 01278286058; Sat, 2 Nov 2013 14:14:57 -0700 (PDT)
Date: Sat, 2 Nov 2013 16:14:45 -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: Sat, 02 Nov 2013 21:15:04 -0000

On Fri, Nov 01, 2013 at 08:53:13PM -0700, Robert Ransom wrote:
> Nico Williams proposed omitting all nonces from (EC)DHE handshakes and
> shared secrets in a future version of TLS.  My objection to that
> proposal was that servers need to ensure that *something* in the
> handshake is fresh, and if that is not a nonce, they will need to
> ensure that at least one of the DH keypairs is new.  I thought it was
> obvious that the reason for that was to prevent an attacker from
> replaying the client DH public key and causing the server to reuse a
> session key.  (It was obvious to Nico.)

If either party wants to reuse a DH key then all they have to do to make
it safe is also send a counter for salting.  The counter would reveal
some information, so it may have to look random -- like a nonce -- and
anyways, the other party can't validate anything about that counter.
BUT, a) it's optional (if you don't reuse DH keys, you don't reuse
session keys), b) it's *small*, much smaller than 32 bytes.

Large nonces and explicit random IVs form a great subliminal channel.
Taking direct outputs from a Dual_EC DRBG-style RNG for 32 byte nonces
in TLS handshake messages makes you vulnerable to attack via the RNG.
While having tiny nonces (or no nonces if not reusing your DH key) and
random-IV-free cipher modes makes such attacks much harder to mount
because the total number of bits of subliminal channel becomes fixed and
is way less than the number needed for that sort of attack.

Clearly there's a trade-off here:

 - no nonces -> no DH key reuse

 - large nonces -> no constraints on DH key reuse

 - small nonces -> limited number of DH key reuses


 - large nonces facilitate some attacks via subliminal channels and RNG

 - no nonces (and no explicit random IVs) -> no subliminal channels

 - small nonces -> lower subliminal channel bandwidth

There's no reason to pick one for all implementations.  And there's
reason to avoid large nonces.

> In any case, for the sake of security, performance, and simplicity,
> ciphersuites should be able to rely on the handshake layer to not
> generate the same session key twice.

Then GCM and friends are out.  They fail catastrophically with key
reuse.  But I think your concern is misplaced -- see above.