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

Robert Ransom <> Sat, 02 November 2013 00:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0181411E8156 for <>; Fri, 1 Nov 2013 17:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1OgPPE4MiyBM for <>; Fri, 1 Nov 2013 17:38:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c02::234]) by (Postfix) with ESMTP id 68D3611E8136 for <>; Fri, 1 Nov 2013 17:38:16 -0700 (PDT)
Received: by with SMTP id w7so2994372qeb.39 for <>; Fri, 01 Nov 2013 17:38:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nWksHWp4DOF47Mw5NKsSh1Uj0nmETaVl75fv40DTU4w=; b=li09p/2p+iYmVWnv2KWgFXDc1+EPLSnZrCfrInOaxMWGSii/hZEhYGCbh1cPN4eCN0 iU2xUMk+sm9jEKoqaJ0GmB90hoz8ukigeR35fbm/QShMYy8/FdEluPcY4R0nTxvuw16O u0RiRx3mz3baz8NlIh8rrJMCVqf/NVhwCOcllby/kafaXEza68LvLCjVH+navSLTozEV U5PalOYdBkfWM+7+SEvVc0RV3ExjJYpsJHX+gfdEW6n5U6EyzXagbJv5W8AVrw9Rf+/T rMWXZK60GZh07vnVXsGDoBYZAvv6hc3b8owai+7fjE6Y/sGOHzZtc4iFs3ZF03rN9M2M 0HWQ==
MIME-Version: 1.0
X-Received: by with SMTP id z15mr7389441qef.27.1383352696012; Fri, 01 Nov 2013 17:38:16 -0700 (PDT)
Received: by with HTTP; Fri, 1 Nov 2013 17:38:15 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Fri, 1 Nov 2013 17:38:15 -0700
Message-ID: <>
From: Robert Ransom <>
To: Dan Harkins <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 02 Nov 2013 00:38:17 -0000

On 11/1/13, Dan Harkins <> wrote:
> On Fri, November 1, 2013 4:13 pm, Nico Williams wrote:

>> 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).
>   It has nothing to do with key derivation, it's to prevent a small
> sub-group
> attack. Sending a nonce does not prevent this attack since it's just going
> to
> be another known for the attacker to use when running through the small
> sub-group looking the right secret.

Small-subgroup attacks are entirely orthogonal to whether a server can
be caused to reuse a session key.  (Reusing a session key destroys the
security properties of many bulk encryption methods, including all
stream ciphers, regardless of whether the server's DH secret key is

>>> regardless of whether a nonce is sent or not.
>> For some curves there's no need to validate the client's public key.
>   Which curves would those be?

Curve25519 ECDH implementations which follow the specification in Dr.
Bernstein's paper do not leak any information about the server's
secret key under any active attack.  They prevent small-subgroup
attacks by using the Montgomery ladder on a curve with a secure
quadratic twist, and by generating all secret keys to be divisible by
8 (the LCM of the orders of small subgroups).

Robert Ransom