Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd

Trevor Perrin <trevp@trevp.net> Thu, 05 December 2013 18:02 UTC

Return-Path: <trevp@trevp.net>
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 5CF431AE123 for <tls@ietfa.amsl.com>; Thu, 5 Dec 2013 10:02:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622] 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 TFXW3_-RDTpi for <tls@ietfa.amsl.com>; Thu, 5 Dec 2013 10:02:00 -0800 (PST)
Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8811D1AE132 for <tls@ietf.org>; Thu, 5 Dec 2013 10:02:00 -0800 (PST)
Received: by mail-we0-f179.google.com with SMTP id q59so16695401wes.24 for <tls@ietf.org>; Thu, 05 Dec 2013 10:01:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3GPfeFuFTZXrywHoVjE1A60G7RUc84kbiQqO2Xt9I10=; b=VKIX7UI2wrXr/gHgSmbVKrHeDIAw2mP0hXh1Lqq4akdDGun9SmUIKV4cpuo0tAv2dR /WJ65aauJF86NOoPIIeTEnH9RwElLLfEb35XSVAQm44zb25swRdwc1/qowpTJ0pzmp+t FZO61WYaPd7XXuMleHN1NkKZqjxGtc0HMbCJFKojvG0vpda0zssZjulUE8e0KOYs1f2w Hxl19mZGk4/AKiY8nnhbkU+56RO3yda+q3JmuCz4NPFQ7MPO53SAnsN7lgpjr3/j3fUj G6Vb7NQbt8P55wTLSpiopeyyZ4DtLFt/wlFrXO2lusVB4HzFQQyzn3LJWgNKfs+kQRsV D1aQ==
X-Gm-Message-State: ALoCoQnFqEWD5IkHC1YqdKNvdynK3d8PNhHdLANzpycOQVln/w+3Fx+2+XHblVtbpkJX08FZ8DbU
MIME-Version: 1.0
X-Received: by 10.180.108.162 with SMTP id hl2mr5866wib.56.1386266516654; Thu, 05 Dec 2013 10:01:56 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Thu, 5 Dec 2013 10:01:56 -0800 (PST)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com> <CACsn0cmtP_dF7N2op4DZUwR8t-fW30GmtdqQoteZ+9Y0oH3dUg@mail.gmail.com> <a4b1729af4966e99df1582943f02a0a8.squirrel@www.trepanning.net> <CACsn0cksrU2GErd6FkZPkXKXK4pSJhTbBoJ-0C-14jsM=UY2iQ@mail.gmail.com> <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net> <CACsn0c=PnB2CA8rpNtcOp6RRLNWHEPN-aN+AdWSF7FJM2wZOog@mail.gmail.com> <6d86c3be1741ed14992ec8662e0d32c7.squirrel@www.trepanning.net> <CADMpkcKTAARYK2id27T44eVyx6gF24mkt9nAkUZbSmwtEtd2gg@mail.gmail.com> <6c129fd89a9e5953ba844e4e1d1e6e98.squirrel@www.trepanning.net>
Date: Thu, 5 Dec 2013 10:01:56 -0800
Message-ID: <CAGZ8ZG0n7AFWc_WpxLzKbhnRxz8hkQAD-j8VDtX_GOHD5Nc6nw@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
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: Thu, 05 Dec 2013 18:02:12 -0000

On Thu, Dec 5, 2013 at 9:15 AM, Dan Harkins <dharkins@lounge.org> wrote:
>
> On Thu, December 5, 2013 3:48 am, Bodo Moeller wrote:
>> Dan Harkins <dharkins@lounge.org>rg>:
>>
>> The exchange was reviewed by the CFRG with, as Joe noted, satisfactory
>>> results.
>>
>>
>> While it is true that Joe noted that, I think the point of the present
>> discussion is that the protocol wasn't actually reviewed by the CFRG with
>> satisfactory results.
>
>   No, that's not really true.  There is a difference between "your
> protocol has
> not been proven secure" and "your protocol has a security flaw". And while
> the former has been pointed out on this list and the CFRG list, the later
> has not.

Yes, it has.  Bodo pointed out a security flaw.


>   You have pointed out an issue with using an in-band server-provided
> domain parameter set and I'm going to address that in a subsequent version.
> That's not really a flaw in the key exchange, it's how the key exchange has
> been inserted into TLS and it can be addressed by some text rewrite. I
> am genuinely thankful for your comment and I will address it in a
> subsequent version.
>
>   The present discussion on the list boils down to these subjects:
>
>   1) there's no security proof and that is unacceptable (Rene, Watson)
>   2) there's nothing special about this protocol so why don't you (being
>       me) spend your time working on something else that we (Rene,
>       Watson) think is better.
>   3) the TLS-pwd benefits and your use cases are not compelling to
>       me (Trevor).
>
> The response to #1 is that security proofs have never been required
> and we have standards-track protocols today that are susceptible to
> offline dictionary attack (every PSK cipher suite). So it's an appeal to a
> process that does not exist.

At Watson points out, times have changed and the bar is higher now.

Regarding PSK: It does not attempt to be a PAKE.  Bringing it up here
is irrelevant.


> The response to #2 is that lack of implementation of these other
> protocols has been hampered by patents

See the discussion around SRP that occurred when you first presented
this.  Any patent FUD which *might* have existed, once, has expired:

http://www.ietf.org/mail-archive/web/tls/current/msg08203.html
http://www.ietf.org/mail-archive/web/tls/current/msg08191.html

Additionally, developments such as Elligator and AugPAKE hold promise
for protocols that have both security proofs *and* no IPR encumbrance.


> and TLS-pwd is not
> patented (and the underlying dragonfly key exchange is not patented
> either). Theoretically I think there are some elegant alternatives to
> TLS-pwd but practically I don't think there are. Regardless though,
> there is nothing stopping Rene and/or Watson from doing any work
> on any other protocol they think should be advanced. Since I am not
> their slave^H^H^H^H^Hgrad student I do not feel compelled to
> throw away my work and write papers and wait years as has been
> suggested.
>
> (The little uptake in PAKE protocols in the IETF in the recent years is
> the result of people following me around from EMU to IPsecme and
> now to TLS and after I do the leg work and present a dragonfly-style
> exchange someone else comes along and says "hey, me too").

People like Tom Wu, Nikos, Quinn Slack, myself, and many others did
the "legwork" for a TLS PAKE years ago (TLS-SRP).  It was deployed in
several TLS libraries, some commercial products, and browser patches
were attempted.

We learned something very significant about TLS PAKE:  Almost no-one
wants it.  Providing usernames in the clear is an unacceptable leak of
information, and front-end TLS machines are rarely where sites wish to
perform user authentication.


> The response to #3 is: so? There is rarely uniformity in viewpoints
> as everyone's experience is different. Now there's a choice and if
> the benefits of one are not compelling then be happy you can
> choose the other.

The benefits of *both* are uncompelling.  The low uptake of TLS/SRP
has nothing to do with this draft's cryptographic differences.  It has
to do with architectural issues with the approach, which your draft
does not improve on.


>   To sum, there has been no demonstration of a flaw against the
> dragonfly protocol, just some people unhappy that I don't live up
> to their standards or that my views of what is important in a PAKE
> protocol is not congruent to theirs.

To sum:  TLS already has an ad-hoc PAKE which is serviceable for those
few application which want such a thing.  We don't need another one.


Trevor