Re: [TLS] What would make TLS cryptographically better for TLS 1.3
"Dan Harkins" <dharkins@lounge.org> Sat, 02 November 2013 02:13 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 33D7011E8142 for <tls@ietfa.amsl.com>; Fri, 1 Nov 2013 19:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.94
X-Spam-Level:
X-Spam-Status: No, score=-5.94 tagged_above=-999 required=5 tests=[AWL=0.325, 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 DMTIoOgRRqOT for <tls@ietfa.amsl.com>; Fri, 1 Nov 2013 19:13:45 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id F3D8711E80E7 for <tls@ietf.org>; Fri, 1 Nov 2013 19:13:44 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 873AA10224008; Fri, 1 Nov 2013 19:13:44 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 1 Nov 2013 19:13:44 -0700 (PDT)
Message-ID: <e5081bc3784fe15976397ccf73eee71f.squirrel@www.trepanning.net>
In-Reply-To: <CABqy+sq=9ue=iNkUEzrddJLdYRdAWk5YRz43sR2DV2Xrv5CHBQ@mail.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> <7e7cd08953358f9e9344d0afdb2e37bf.squirrel@www.trepanning.net> <CABqy+sq=9ue=iNkUEzrddJLdYRdAWk5YRz43sR2DV2Xrv5CHBQ@mail.gmail.com>
Date: Fri, 01 Nov 2013 19:13:44 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Robert Ransom <rransom.8774@gmail.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: Sat, 02 Nov 2013 02:13:50 -0000
On Fri, November 1, 2013 5:38 pm, Robert Ransom wrote: > On 11/1/13, Dan Harkins <dharkins@lounge.org> 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 > disclosed.) "caused to reuse a session key"? Who said anything about that. My statement was in response to yours that said: "If the server sends a nonce during DHE/ECDHE key exchange, the server can safely reuse its DH keypair for multiple clients WITH NO FURTHER DESIGN OR IMPLEMENTATION CONSIDERATIONS (emphasis mine)". Again, if the server decides to reuse its DH key pair with multiple clients then it needs some implementation considerations, namely it needs to protect itself against a small sub-group attack. And this is regardless of whether it sends a nonce or not. It has nothing to do with key derivation. Also, your statement that "[r]eusing a session key destroys the security properties of...all stream ciphers" leaves a bit of quantification up to the reader. It's reuse of a session key _and_ a counter/nonce, and that's only if you are not using SIV mode. >>>> 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). Thanks for the reference. I'll check it out. 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