Re: [TLS] New cipher suites for SRP

Jeffrey Walton <> Mon, 20 July 2015 12:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D2AE51A6F39 for <>; Mon, 20 Jul 2015 05:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PGt_9pcwpabw for <>; Mon, 20 Jul 2015 05:15:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0668B1A1B8E for <>; Mon, 20 Jul 2015 05:15:06 -0700 (PDT)
Received: by igbij6 with SMTP id ij6so1108790igb.3 for <>; Mon, 20 Jul 2015 05:15:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=m2jqQV9Irgy54yMAYBIpiPQsYOEwJII1K3fBRYEuERE=; b=jjm2x//b7s/enfxElxJrR1wpCbHqjhKSqqDJGg2HtCA0pFAt8iqADbNZlDECdeguGu Zmvhvh6fo6nLnhNP9T+bp9R1HMRCvU/oXuU0iPuZrwKnvW4+/exJKThtBBnSWIL8eX13 bzIqljf7ixHuOjk1R4zp/4h2wVMdbSHrZtw5S7F8uCmdxBzbkitZY6HYv4k8UQUY7xX1 Eeu60w6kUXjdNJzv9gepjMQZhy7mi2eV6zC0SQyAaL5MAsIqOgCWMWN3poHKAIPjxg9k taLOCvBhiGR+McMRrfZDTmDhPa+HzT8PpYAjfWzisFZcJbStJcd7wcdTRassYo1Gf0wg y8hQ==
MIME-Version: 1.0
X-Received: by with SMTP id rj7mr14248810igc.59.1437394505583; Mon, 20 Jul 2015 05:15:05 -0700 (PDT)
Received: by with HTTP; Mon, 20 Jul 2015 05:15:05 -0700 (PDT)
In-Reply-To: <>
References: <> <> <m2d20hbz0z.fsf@localhost.localdomain> <> <> <> <> <>
Date: Mon, 20 Jul 2015 08:15:05 -0400
Message-ID: <>
From: Jeffrey Walton <>
To: =?UTF-8?Q?Schmidt=2C_J=C3=B6rn=2DMarc?= <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] New cipher suites for SRP
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Jul 2015 12:15:16 -0000

>>This is possible, but you’d need to have the client and server negotiate
> based on
>>what they have.  For example, if the server has a SRP verifier from the
> current
>>protocol, but the client has a stored PBKDF2 hash of the password for that
> server,
>>they cannot communicate and would need to pick a different cipher suite.  I
> am not
>>sure how you can do this without revealing the existence of an account
> under some
>>circumstances.  So this might be a situation where fewer protocol options
> is better.
> Of course both sides have to agree on  common protocol details: You could do
> this by specifying that you want to use PAKE and refine in an extension a
> set of schemes that you are capable of.

There's not much to negotiate. I would expend minimal energy on
negotiating parameters. The server holds the verifiers, and they are
set in stone. To get a verifier, the user needs to be pre-provisioned.

Spend energy on keeping the identity private.

If you want to go something cool, add an OTP as a second factor. There
are two ways to do it based on the math around the verifiers (that I
am aware). I have implementations for both in Crypto++, if interested.