Re: [TLS] What would make TLS cryptographically better for TLS 1.3
"Dan Harkins" <dharkins@lounge.org> Fri, 01 November 2013 19:00 UTC
Return-Path: <dharkins@lounge.org>
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 1969C21E8547 for <tls@ietfa.amsl.com>; Fri, 1 Nov 2013 12:00:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.965
X-Spam-Level:
X-Spam-Status: No, score=-4.965 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
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 U4UT2DqzVeUY for <tls@ietfa.amsl.com>; Fri, 1 Nov 2013 12:00:53 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E2C8021E8279 for <tls@ietf.org>; Fri, 1 Nov 2013 12:00:53 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id DF90D10224008; Fri, 1 Nov 2013 12:00:52 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 1 Nov 2013 12:00:53 -0700 (PDT)
Message-ID: <7790984d7cbbba7ed78e84a6ff9253f0.squirrel@www.trepanning.net>
In-Reply-To: <20131031230955.GB32733@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com>
Date: Fri, 01 Nov 2013 12:00:53 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Nico Williams <nico@cryptonector.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
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: Fri, 01 Nov 2013 19:00:59 -0000
On Thu, October 31, 2013 4:09 pm, Nico Williams wrote: [snip] > - 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. > > <aside> > > 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 > tolerable. > > </aside> In the interest of lessening nonce and IV bytes, especially ones that are security-critical there is always SIV mode (RFC 5297). That provides authenticated encryption and only expands the packet by the number of bits equal to the blocksize of the underlying cipher. You can add a nonce as additional AAD but it's not necessary and security isn't voided if such a nonce/counter gets reused. You get a mode that is less fragile, and doesn't expand the frame as much, at the cost of two passes of the data. I'm not sure about Perry's proposed mode, and I'd be interested in reading more about it, but SIV has a security proof in the paper by Rogaway and Shrimpton that defined SIV. regards, Dan.
- [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