Re: [TLS] I-D Action: draft-ietf-tls-pwd-04.txt

Nico Williams <nico@cryptonector.com> Tue, 01 April 2014 19:57 UTC

Return-Path: <nico@cryptonector.com>
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 866781A0A0E for <tls@ietfa.amsl.com>; Tue, 1 Apr 2014 12:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.303
X-Spam-Level:
X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347] autolearn=no
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 ujvzS68imPZV for <tls@ietfa.amsl.com>; Tue, 1 Apr 2014 12:57:47 -0700 (PDT)
Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E44151A09E2 for <tls@ietf.org>; Tue, 1 Apr 2014 12:57:45 -0700 (PDT)
Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 64ABA2005D107 for <tls@ietf.org>; Tue, 1 Apr 2014 12:57:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=rsy5A4A1TOKv47Wb6Wrs xYBjvOk=; b=CsUgJj3YV+oh10kVGFfNp+VnLd3BjrkC5RW+iJKHLc6/f4r9z8oH 5T7QAYbBUbwqOIpl1fZEcShtd4zdm85XNT5sJwLd/yKR9mDai2yAcLDklnLnKXNE BSIs8TsoksA+WOBO1XYsYsqeyXmQGLiFo7RzSsSXRKYObgexI4OGDts=
Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id 1A0672005D100 for <tls@ietf.org>; Tue, 1 Apr 2014 12:57:41 -0700 (PDT)
Received: by mail-we0-f177.google.com with SMTP id u57so6690491wes.22 for <tls@ietf.org>; Tue, 01 Apr 2014 12:57:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6S+I3YNzZON0IQn1wKU9xH95Jrh8AUZYNe6UeN0XkBE=; b=b3ZPeP3f12AVi777N2XpWqRJTm28NIdhGJlCgZZsC+e814y+5Sf+0hJL25MzFiPKZK /Tn7cDNQ4dDSu1b5JxPjMTPjvrXorOZ6RmqZyCWNEVmy9BUsvzFnk9Xl4k0oyglD6p4o xWNqDNwmrP88Qd3S+WnFVKyxG9K5YsAgx50GpGhG2LMisdKpCjRh/1gIFsJh5EopX2sK a7cy8GTsBaaoZIXRhIODlulL8je76Qb9Kb6/Eeph0910SyyI/UXmBTv23Y2VRTYARKIi xuX77SOpyDkl+F+zvuWNSlFEez4FNjEWHiDNOsM7EZtifwg3kzeZr8NeJzKaMnYR+D+6 nUSw==
MIME-Version: 1.0
X-Received: by 10.194.57.239 with SMTP id l15mr23928998wjq.40.1396382260857; Tue, 01 Apr 2014 12:57:40 -0700 (PDT)
Received: by 10.217.129.197 with HTTP; Tue, 1 Apr 2014 12:57:40 -0700 (PDT)
In-Reply-To: <f8dc8cec46f6126146a7afa2421e43de.squirrel@www.trepanning.net>
References: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> <CACsn0c==pRzDKd7G=eAhds=o9qexqe9Jb3DgNC9gzh-6xaKcAQ@mail.gmail.com> <dd67ab76dee19a82a0dfcdaa6512b905.squirrel@www.trepanning.net> <CACsn0ckQiNODB9DLj5XpcQDH2ykfD76CoV11-R4JJL+1_Vogfw@mail.gmail.com> <f8dc8cec46f6126146a7afa2421e43de.squirrel@www.trepanning.net>
Date: Tue, 01 Apr 2014 14:57:40 -0500
Message-ID: <CAK3OfOjdJecL1NG_AwfMgkaK8gupLyrttuqh5=MidRhA64qndA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sjEzpVD03E56LxJOQ2hsEandA80
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-pwd-04.txt
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: Tue, 01 Apr 2014 19:57:48 -0000

On Fri, Mar 28, 2014 at 7:07 PM, Dan Harkins <dharkins@lounge.org> wrote:
>> Why is a multi-party computation ala Socialist Millionaire's protocol
>> in OTR not feasible? That establishes a secure channel based on a
>> password shared on both ends in a way that is provably secure.
>> Aug-PAKE can easily be made to work symmetrically: why can't you use
>> that?
>
>   There is no draft specifying a multi-party computation ala the
> Socialist Millionaire's protocol in TLS, much less one that is as
> mature as TLS-pwd. Aug-PAKE doesn't work in TLS, as shown
> by draft-shin-tls-augpake-- what's conveyed in the ClientKeyExchange
> structure since the client's contribution has been overloaded into
> the ClientHello? Basically, the client must initiate in Aug-PAKE and
> that forces a square peg into a round hole, or introduces extra
> rounds.

IMO:

 - user authentication generally belongs at the app layer, with
channel binding to TLS,

however

 - since there are applications where having userauth in lower layers
is convenient, it's OK to have this option in TLS,

but

 - we should use an augmented ZKPP for this.  If that means extra
round-trips or starting sooner (in the client's first message), so be
it.  We shouldn't be so constrained by the "TLS state machine" that we
make no real progress.

Finally:

 - we should use well-understood, well-aged, believed-secure
protocols.  We are constrained here by IPR, but there are protocols
which can reasonably cut through IPR FUD (e.g., J-PAKE).

Nico
--