[TLS] removal of nonces [was: What would make TLS cryptographically better for TLS 1.3]
Nikos Mavrogiannopoulos <nmav@gnutls.org> Sat, 02 November 2013 07:26 UTC
Return-Path: <n.mavrogiannopoulos@gmail.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 1E62E11E81CC for <tls@ietfa.amsl.com>; Sat, 2 Nov 2013 00:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 X+-c0rY-gmrO for <tls@ietfa.amsl.com>; Sat, 2 Nov 2013 00:26:42 -0700 (PDT)
Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6946011E81CB for <tls@ietf.org>; Sat, 2 Nov 2013 00:26:41 -0700 (PDT)
Received: by mail-ee0-f54.google.com with SMTP id c50so160314eek.13 for <tls@ietf.org>; Sat, 02 Nov 2013 00:26:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=Z4EOm8xhfuJQ/c/5a2O60x0ZO/8vuhzIFBPsqy3QYsM=; b=frIKpJwj8Ipo2cHjTUu6axYnKqh/Qmq0sG5A9uTmLtU70pNpoL0GVZknRyUPaUddr0 LZJX+fDT8AQd23SwP9JXDbyNWMctjOGnfrNfN9UzdKtSzQw4I+rZ8fZThkXPw+aoeUn1 NHAz4YNgn+8TaTItIoPopd+Nd8m0R1H9CzmX7l4oOD6oZGAqOLu3FJ+yzxli/ChQa3Hq xvIjDJqJ29YMrZPpLE1KPwWGQQKrSoCC7iSiwHuzqrRlgY3d3rc6XcMsZuXlar1vW+eu 014TRBBfkfVRIL3T9pcZkagxeGCoJzwgR9DqjPZfjMgkGIdVxetaXRS4sdb08ciBdV6l Yqgg==
X-Received: by 10.15.83.9 with SMTP id b9mr6463281eez.34.1383377200578; Sat, 02 Nov 2013 00:26:40 -0700 (PDT)
Received: from [10.100.2.17] (ip-62-245-100-42.net.upcbroadband.cz. [62.245.100.42]) by mx.google.com with ESMTPSA id h45sm17195437eeg.5.2013.11.02.00.26.39 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Nov 2013 00:26:39 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <5274A92A.4030508@gnutls.org>
Date: Sat, 02 Nov 2013 08:26:34 +0100
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9
MIME-Version: 1.0
To: tls@ietf.org
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com>
In-Reply-To: <20131031230955.GB32733@gmail.com>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [TLS] removal of nonces [was: 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 07:26:43 -0000
On 11/01/2013 12:09 AM, Nico Williams wrote: > - 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. Not really. Nonces are needed even in DHE ciphersuites. The nonces in TLS make sure that the signatures from both parties are fresh and only valid for this session (i.e., cannot be taken and re-used in another session). See how PKINIT Kerberos has issues when used with smart cards, just because it saved a round-trip by not sending a server nonce. While one could select a message order in order to avoid using nonces by using the DH public keys as such and maintain security (i.e., one cannot save a round-trip), what would that buy? It would just make the TLS shell weaker that would resemble less of a generic security protocol with algorithm agility. regards, Nikos
- [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