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.