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

Trevor Perrin <> Thu, 05 December 2013 18:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5CF431AE123 for <>; Thu, 5 Dec 2013 10:02:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TFXW3_-RDTpi for <>; Thu, 5 Dec 2013 10:02:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8811D1AE132 for <>; Thu, 5 Dec 2013 10:02:00 -0800 (PST)
Received: by with SMTP id q59so16695401wes.24 for <>; Thu, 05 Dec 2013 10:01:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id hl2mr5866wib.56.1386266516654; Thu, 05 Dec 2013 10:01:56 -0800 (PST)
Received: by with HTTP; Thu, 5 Dec 2013 10:01:56 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Thu, 5 Dec 2013 10:01:56 -0800
Message-ID: <>
From: Trevor Perrin <>
To: Dan Harkins <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" <>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
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: Thu, 05 Dec 2013 18:02:12 -0000

On Thu, Dec 5, 2013 at 9:15 AM, Dan Harkins <> wrote:
> On Thu, December 5, 2013 3:48 am, Bodo Moeller wrote:
>> Dan Harkins <>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:

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.