Re: [TLS] New cipher suites for SRP

"Dan Harkins" <dharkins@lounge.org> Wed, 15 July 2015 19:38 UTC

Return-Path: <dharkins@lounge.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 BFA651A1AE8 for <tls@ietfa.amsl.com>; Wed, 15 Jul 2015 12:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 S5OokdHrtzLL for <tls@ietfa.amsl.com>; Wed, 15 Jul 2015 12:38:03 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7264D1A1A9F for <tls@ietf.org>; Wed, 15 Jul 2015 12:38:03 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D1BD9A888132; Wed, 15 Jul 2015 12:38:02 -0700 (PDT)
Received: from 24.43.232.186 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 15 Jul 2015 12:38:03 -0700 (PDT)
Message-ID: <6ce70b2d45a6aa67aae04ef7e6940ca7.squirrel@www.trepanning.net>
In-Reply-To: <36814552.ToKCXeCVxV@pintsize.usersys.redhat.com>
References: <20150626234801.ED7DDE04DA@smtp.hushmail.com> <201506262101.57121.davemgarrett@gmail.com> <m2d20hbz0z.fsf@localhost.localdomain> <36814552.ToKCXeCVxV@pintsize.usersys.redhat.com>
Date: Wed, 15 Jul 2015 12:38:03 -0700 (PDT)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Hubert Kario" <hkario@redhat.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
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/NcEXJWGWcIjQjMGPxTwdsD3xPZc>
Cc: tls@ietf.org, Geoffrey Keating <geoffk@geoffk.org>
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: Wed, 15 Jul 2015 19:38:04 -0000


On Mon, June 29, 2015 4:31 am, Hubert Kario wrote:
> On Friday 26 June 2015 20:39:24 Geoffrey Keating wrote:
>> 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.
>
> +1, provided we do two more things:
>
>  - Change the negotiation so that user name is not exchanged in the clear
>  - Change key exchange to do PFS

  TLS-pwd already supports both of these. It also supports ECC too,
which is problematic with the current SRP protocol.

  regards,

  Dan.