Re: [TLS] New cipher suites for SRP

Geoffrey Keating <geoffk@geoffk.org> Sat, 27 June 2015 03:39 UTC

Return-Path: <geoffk@geoffk.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286A71B2E01 for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 20:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Level:
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEThcY5OdtDQ for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 20:39:25 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322561B2DFE for <tls@ietf.org>; Fri, 26 Jun 2015 20:39:25 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 1A1C233D1D0; Sat, 27 Jun 2015 03:39:24 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Dave Garrett <davemgarrett@gmail.com>, tls@ietf.org, "Attila Molnar" <attilamolnar@hush.com>
References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> <201506262101.57121.davemgarrett@gmail.com>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: 26 Jun 2015 20:39:24 -0700
In-Reply-To: <201506262101.57121.davemgarrett@gmail.com>
Message-ID: <m2d20hbz0z.fsf@localhost.localdomain>
Lines: 39
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/53-ozJ7LUM8p88iyioWOqrVo2bA>
Subject: Re: [TLS] New cipher suites for SRP
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 27 Jun 2015 03:39:27 -0000

Dave Garrett <davemgarrett@gmail.com> writes:

> On Friday, June 26, 2015 07:48:01 pm Attila Molnar wrote:
> > Currently SRP cannot be used with newer crypto primitives such as ciphers in
> > AEAD mode or SHA-2 due to the lack of cipher suites enabling these.
> > There's only 3DES and AES-CBC with SHA-1.
> > 
> > Would there be support for expanding the SRP cipher suites?
> 
> I don't think it's a good idea to add new SRP cipher suites.
> 
> Instead, I think redefining SRP as an extension to PSK would make more sense. Use (EC)DHE_PSK cipher suites with an updated SRP extension to get similar capabilities. This would make updating SRP to use newer crypto much easier, as modern PSK cipher suites are easier to get standardized. The current SRP spec actually already appears to rely on PSK identity alert codes.

The problem with that is that there are surely many use cases where
you're willing to do SRP, or if no SRP you can do a regular ECDHE and
prompt for the username/password, but PSK is too insecure.

I've been thinking an improved SRP would be useful.  It should:

- Specify Modern cipher and hash algorithms as mentioned above

- Replace the existing SHA1+seed with a password whitening function
  like PBKDF2, so that in the event of a compromised server cracking
  the password is harder, and also making online password guessing
  attacks (sending lots of username+password pairs to the server) more
  expensive*

- Deprecate the 1024-bit and the 1536-bit group, and the previous SRP
  ciphersuites; and say that these should only be chosen if the server
  has a legacy verifier for a particular username which requires
  them.


*: You can even keep two verifiers for each account: a 'fast' one
 where PBKDF2 should execute in a fraction of a second, and a 'slow'
 one where PBKDF2 might take 15-30 seconds, and pick between them
 based on recent account history, IP address reputation, or whatever.
 It costs the server no more to use the 'slow' path but anyone
 guessing passwords will find it much less effective.