Re: [TLS] Should TLS 1.3 use an augmented PAKE by default?

Peter Sylvester <peter.sylvester@edelweb.fr> Wed, 19 March 2014 16:21 UTC

Return-Path: <peter.sylvester@edelweb.fr>
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 9C8EB1A0790 for <tls@ietfa.amsl.com>; Wed, 19 Mar 2014 09:21:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 eeJv1W9nOT8u for <tls@ietfa.amsl.com>; Wed, 19 Mar 2014 09:21:25 -0700 (PDT)
Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0246D1A07AF for <tls@ietf.org>; Wed, 19 Mar 2014 09:21:25 -0700 (PDT)
Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id B262F5E03D; Wed, 19 Mar 2014 17:15:43 +0100 (CET)
Received: from [127.0.0.1] (unknown [192.168.11.68]) by mx1.on-x.com (Postfix) with ESMTP id 93B2C5E00F; Wed, 19 Mar 2014 17:15:43 +0100 (CET)
Message-ID: <5329C3FB.9030405@edelweb.fr>
Date: Wed, 19 Mar 2014 17:21:15 +0100
From: Peter Sylvester <peter.sylvester@edelweb.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: tls@ietf.org
References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <CALCETrV7_j3dLuaUeQ1pXM=fkrO9Q9svHSC=MaOXQA1nvAQHFQ@mail.gmail.com>
In-Reply-To: <CALCETrV7_j3dLuaUeQ1pXM=fkrO9Q9svHSC=MaOXQA1nvAQHFQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SicQ0_GEEiw58ye2bVbAnr3tMWk
Subject: Re: [TLS] Should TLS 1.3 use an augmented PAKE by default?
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: <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: Wed, 19 Mar 2014 16:21:27 -0000

On 03/19/2014 04:43 PM, Andy Lutomirski wrote:
> On Tue, Mar 18, 2014 at 10:54 PM, Ryan Sleevi <ryan-ietftls@sleevi.com> wrote:

>> TLS SRP's lack of use suggests that there is not a high pressure for
>> deployment here.
>>
>> It's probably worth thinking some about why SRP adoption has been so
>> slow (i don't know the global answer here, but i only know a few folks
>> who are using it)
I remember that years ago, when we implemented SRP
with openssl, I was thinking about the doing same in the NSS.
Well, not enough time.

The reason was the possibility to use the database for
url/login/password

- Browsers have the user/password containers tied to some host.

- A browser can add the ciphersuite but no user in the clienthello
   if the host is not known.

- If the host is known the browser can immediately provide the
   identity (which could be encoded as hash(user@host).

- A password could also be encoded as in Steve Bellovins draft.

This leaves us at the same "inconvenience" having a pop up
for the "PIN" outside the html layer but at least one would not
send a password to a badly authenticated site?

Peter