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

"Dan Harkins" <> Thu, 05 December 2013 18:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6B1B51AE10A for <>; Thu, 5 Dec 2013 10:40:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TAWFCGWwWHA1 for <>; Thu, 5 Dec 2013 10:40:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 972A11AE107 for <>; Thu, 5 Dec 2013 10:40:39 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 09A651022404A; Thu, 5 Dec 2013 10:40:36 -0800 (PST)
Received: from (SquirrelMail authenticated user by with HTTP; Thu, 5 Dec 2013 10:40:36 -0800 (PST)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 5 Dec 2013 10:40:36 -0800 (PST)
From: "Dan Harkins" <>
To: "Trevor Perrin" <>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
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:40:42 -0000

On Thu, December 5, 2013 10:01 am, Trevor Perrin wrote:
> 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 should read the entire email before you respond to it. Like the
very next 6 lines.

>>   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.

  You are appealing to a process that does not exist.

>> 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:

  Yes I am aware that the original EKE patent expired. But EKE cannot be
used with elliptic curves. Now I know elliptic curve support is not a
compelling use case for you but, again, so what?

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

>> 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.

  You are free to not use this protocol as well if you do not find it