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

Robert Ransom <rransom.8774@gmail.com> Fri, 01 November 2013 23:34 UTC

Return-Path: <rransom.8774@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 5D82411E8136 for <tls@ietfa.amsl.com>; Fri, 1 Nov 2013 16:34:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 OeUFOxr+-tzs for <tls@ietfa.amsl.com>; Fri, 1 Nov 2013 16:34:24 -0700 (PDT)
Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC8C11E817B for <tls@ietf.org>; Fri, 1 Nov 2013 16:34:24 -0700 (PDT)
Received: by mail-qc0-f170.google.com with SMTP id n9so2884061qcw.1 for <tls@ietf.org>; Fri, 01 Nov 2013 16:34:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hSTJg9WCOg2/bYvSCfvfP71jDjJdp9R8qwfGzDSpyOw=; b=0VQAptepn3NAJYDPN41NwwyxJAIRyhaoMMUK7XDhMc7U43NW+jxON2HIhP3CjAbWo1 whiqNW3cg6UgdqaU8ma5qFx/uMx08OxZ+zjCaBk3z2Wa9WggNFGfA5oHoT7bUJGSQeDB YXcyLoubWeJIYpH2+dP8nTc33w1mxDCmfo0EjqXbQkU0vV0dVu9JjfdBa/8HN4Pcaixg 2I63YyAvSaO+V8kCtBrRHDco7p/tTPvYjSvEO/EhaXXb+NKuJefo1EemJTB5fN++/no8 2SnLiNbPHH9TDlRGMBppykmoL0HJ1jgKQS8rQYO/IQscrnJ+qSnPXug2+aV+MmWGsolQ rfSw==
MIME-Version: 1.0
X-Received: by 10.49.24.202 with SMTP id w10mr7361625qef.12.1383348864147; Fri, 01 Nov 2013 16:34:24 -0700 (PDT)
Received: by 10.229.12.198 with HTTP; Fri, 1 Nov 2013 16:34:24 -0700 (PDT)
In-Reply-To: <20131101231342.GG32733@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>
Date: Fri, 1 Nov 2013 16:34:24 -0700
Message-ID: <CABqy+sq=qdy1AH6CbHi55y--5svdc5A=upE0zsLsd2c4jZyH4g@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset=UTF-8
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 23:34:25 -0000

On 11/1/13, Nico Williams <nico@cryptonector.com> wrote:
> On Fri, Nov 01, 2013 at 03:38:06PM -0700, Dan Harkins wrote:
>> On Fri, November 1, 2013 2:34 pm, Robert Ransom wrote:
>> > On 10/31/13, Nico Williams <nico@cryptonector.com> 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.  This means that counter modes are better, for example,
>> >> than
>> >>    CBC modes.
>> >
>> > If the server sends a nonce during a DHE/ECDHE key exchange, the
>> > server can safely reuse its DH keypair for multiple clients with no
>> > further design or implementation considerations.
>>
>>   I don't believe that's true. If the server reuses its ephemeral D-H key
>> then caveat emptor applies-- it should validate the client's public key,
>
> Agreed.  A small nonce should suffice for key derivation if either party
> reuses their supposedly-ephemeral DH keys.  By "small" I mean "not
> nearly as large as 32 bytes, i.e., not enough to suffice for a
> Dual_EC-type backdoored RNG attack".  The party reusing a key should
> send some such small nonce, possibly a 64-bit nonce.  In any case, the
> client ought not be reusing ephemeral DH keys, and any server that does
> should be rotating them often (like SSHv1 used to).

The server should be allowed to send up to 32 bytes of nonce.  Some
servers will want to conceal the lifetime of their keypair by
generating nonces using a counter encrypted or hashed with a secret,
using the cheapest encryption or hash function available; this may be
TEA, AES, SHA-256, or something else, depending on the hardware.  Some
servers will want to use a fast RNG to generate nonces.  32 bytes
should be enough to prevent even a random (or hash-derived) nonce from
repeating; anything less than that may not be enough for some servers.


Robert Ransom