Re: [TLS] draft on new TLS key exchange

Jean-Marc Desperrier <jmdesp@free.fr> Thu, 06 October 2011 00:36 UTC

Return-Path: <jmdesp@free.fr>
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 8ADCE1F0C4A for <tls@ietfa.amsl.com>; Wed, 5 Oct 2011 17:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.856
X-Spam-Level:
X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 3KURNeQGEnw5 for <tls@ietfa.amsl.com>; Wed, 5 Oct 2011 17:36:10 -0700 (PDT)
Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id DD3081F0C41 for <tls@ietf.org>; Wed, 5 Oct 2011 17:36:08 -0700 (PDT)
Received: from [IPv6:2a01:e35:2f1a:f7d0:61eb:1dd1:88b2:6cc5] (unknown [IPv6:2a01:e35:2f1a:f7d0:61eb:1dd1:88b2:6cc5]) by smtp1-g21.free.fr (Postfix) with ESMTP id 6A0AA9400FD; Thu, 6 Oct 2011 02:39:10 +0200 (CEST)
Message-ID: <4E8CF8AD.9020509@free.fr>
Date: Thu, 06 Oct 2011 02:39:09 +0200
From: Jean-Marc Desperrier <jmdesp@free.fr>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0a2) Gecko/20111002 Thunderbird/9.0a2
MIME-Version: 1.0
To: Dan Harkins <dharkins@lounge.org>, tls@ietf.org
References: <ce78cf414ed82d44135ebbb88e32959b.squirrel@www.trepanning.net> <m2ipo3cfi8.fsf@localhost.localdomain> <d096c015393ef5e7683b38bd015cf05b.squirrel@www.trepanning.net>
In-Reply-To: <d096c015393ef5e7683b38bd015cf05b.squirrel@www.trepanning.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] draft on new TLS key exchange
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: Thu, 06 Oct 2011 00:36:10 -0000

On 06/10/2011 01:07, Dan Harkins wrote:
> TLS is rife with drafts and RFCs that have the same aim but go about 
> it differently
Even if there might indeed be quite a few like that in the TLS case, 
it's still against IETF policy.

There should be at least some specific advantage to your approach over 
the other one (or enough existing usage to justify documenting it 
through an experimental RFC), which is far from being proved for now.

SRP has the advantage over the other PAKE to be covered by a defensive 
patent with a royalty free license, which makes it safer to use.

If needed, it's also actually very easy to use SRP in symmetric mode, 
regenerating the verifier from the password on the fly.
Nothing in RFC5054 says how the client sends the verifier to the server 
initially. If you really want to send the password instead, you just can.