Re: [TLS] What would make TLS cryptographically better for TLS 1.3
Nico Williams <nico@cryptonector.com> Sat, 02 November 2013 21:15 UTC
Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2700A11E8241 for <tls@ietfa.amsl.com>; Sat, 2 Nov 2013 14:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.184
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lULRPpCpQrav for <tls@ietfa.amsl.com>; Sat, 2 Nov 2013 14:14:59 -0700 (PDT)
Received: from homiemail-a97.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id ED79011E811D for <tls@ietf.org>; Sat, 2 Nov 2013 14:14:58 -0700 (PDT)
Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 70CD2286059; Sat, 2 Nov 2013 14:14:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=uccQbX9KdEiYM4 LYefiZZvxEoyo=; b=ZTrQm8qh95CgF/M96xNSSd3CoRonxxQcL2fA/wcMNZaCZH PT+oer0ASO90EvwOrM4AU9PIl5xAPSD2Jnt15VRNIeE3LKy1vy3pOnQM6IS39RSa 7VeEmFfM1zPwH3WLtYvyWr0jtu7LJIxz76xqA0iS++7F5Va60TFDt5FHhfyz0=
Received: from gmail.com (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 01278286058; Sat, 2 Nov 2013 14:14:57 -0700 (PDT)
Date: Sat, 02 Nov 2013 16:14:45 -0500
From: Nico Williams <nico@cryptonector.com>
To: Robert Ransom <rransom.8774@gmail.com>
Message-ID: <20131102211441.GA11907@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <CABqy+sof-NtSmZwTNN-x9Ekppz4PYMu2Pr3KjaEUdT7Wzxe7mQ@mail.gmail.com> <4e1772ced74d9347c88a66b123f8878f.squirrel@www.trepanning.net> <20131101231342.GG32733@gmail.com> <7e7cd08953358f9e9344d0afdb2e37bf.squirrel@www.trepanning.net> <CABqy+sq=9ue=iNkUEzrddJLdYRdAWk5YRz43sR2DV2Xrv5CHBQ@mail.gmail.com> <e5081bc3784fe15976397ccf73eee71f.squirrel@www.trepanning.net> <CABqy+sq9pp3hVkDYhZ98AfkXAYcdt2j+fbrFSnCmLteGHYEETg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABqy+sq9pp3hVkDYhZ98AfkXAYcdt2j+fbrFSnCmLteGHYEETg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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 And: - large nonces facilitate some attacks via subliminal channels and RNG attacks - 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. Nico --
- [TLS] What would make TLS cryptographically bette… Watson Ladd
- Re: [TLS] What would make TLS cryptographically b… Nico Williams
- Re: [TLS] What would make TLS cryptographically b… Dan Harkins
- Re: [TLS] What would make TLS cryptographically b… Nikos Mavrogiannopoulos
- Re: [TLS] What would make TLS cryptographically b… Robert Ransom
- Re: [TLS] What would make TLS cryptographically b… Nico Williams
- Re: [TLS] What would make TLS cryptographically b… Robert Ransom
- Re: [TLS] What would make TLS cryptographically b… Robert Ransom
- Re: [TLS] What would make TLS cryptographically b… Dan Harkins
- Re: [TLS] What would make TLS cryptographically b… Watson Ladd
- Re: [TLS] What would make TLS cryptographically b… Nico Williams
- Re: [TLS] What would make TLS cryptographically b… Robert Ransom
- Re: [TLS] What would make TLS cryptographically b… Nico Williams
- Re: [TLS] What would make TLS cryptographically b… Dan Harkins
- Re: [TLS] What would make TLS cryptographically b… Robert Ransom
- Re: [TLS] What would make TLS cryptographically b… Robert Ransom
- Re: [TLS] What would make TLS cryptographically b… Dan Harkins
- Re: [TLS] What would make TLS cryptographically b… Robert Ransom
- Re: [TLS] What would make TLS cryptographically b… Watson Ladd
- [TLS] removal of nonces [was: What would make TLS… Nikos Mavrogiannopoulos
- Re: [TLS] What would make TLS cryptographically b… Andy Lutomirski
- Re: [TLS] What would make TLS cryptographically b… Nico Williams
- Re: [TLS] removal of nonces [was: What would make… Nico Williams
- Re: [TLS] What would make TLS cryptographically b… Robert Ransom
- Re: [TLS] What would make TLS cryptographically b… Ralf Skyper Kaiser
- Re: [TLS] What would make TLS cryptographically b… Ralf Skyper Kaiser
- Re: [TLS] What would make TLS cryptographically b… Nikos Mavrogiannopoulos
- Re: [TLS] What would make TLS cryptographically b… Yoav Nir
- Re: [TLS] What would make TLS cryptographically b… Robert Ransom
- Re: [TLS] What would make TLS cryptographically b… Ralf Skyper Kaiser
- Re: [TLS] What would make TLS cryptographically b… Ralf Skyper Kaiser
- Re: [TLS] What would make TLS cryptographically b… Watson Ladd
- Re: [TLS] What would make TLS cryptographically b… Yoav Nir
- Re: [TLS] What would make TLS cryptographically b… Ralf Skyper Kaiser
- Re: [TLS] What would make TLS cryptographically b… Martin Rex
- Re: [TLS] What would make TLS cryptographically b… Ralf Skyper Kaiser
- Re: [TLS] What would make TLS cryptographically b… Jeff Jarmoc
- Re: [TLS] What would make TLS cryptographically b… Nico Williams
- Re: [TLS] What would make TLS cryptographically b… Yoav Nir
- Re: [TLS] What would make TLS cryptographically b… Johannes Merkle
- Re: [TLS] What would make TLS cryptographically b… Dan Harkins
- Re: [TLS] What would make TLS cryptographically b… Yoav Nir
- Re: [TLS] What would make TLS cryptographically b… Santosh Chokhani
- Re: [TLS] What would make TLS cryptographically b… Ralf Skyper Kaiser