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

"Dan Harkins" <dharkins@lounge.org> Thu, 05 December 2013 18:40 UTC

Return-Path: <dharkins@lounge.org>
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 6B1B51AE10A for <tls@ietfa.amsl.com>; Thu, 5 Dec 2013 10:40:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAWFCGWwWHA1 for <tls@ietfa.amsl.com>; Thu, 5 Dec 2013 10:40:39 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 972A11AE107 for <tls@ietf.org>; Thu, 5 Dec 2013 10:40:39 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 09A651022404A; Thu, 5 Dec 2013 10:40:36 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 5 Dec 2013 10:40:36 -0800 (PST)
Message-ID: <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net>
In-Reply-To: <CAGZ8ZG0n7AFWc_WpxLzKbhnRxz8hkQAD-j8VDtX_GOHD5Nc6nw@mail.gmail.com>
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> <CAGZ8ZG0n7AFWc_WpxLzKbhnRxz8hkQAD-j8VDtX_GOHD5Nc6nw@mail.gmail.com>
Date: Thu, 5 Dec 2013 10:40:36 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Trevor Perrin" <trevp@trevp.net>
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: "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: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 <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 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:
>
> http://www.ietf.org/mail-archive/web/tls/current/msg08203.html
> http://www.ietf.org/mail-archive/web/tls/current/msg08191.html

  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.

https://datatracker.ietf.org/ipr/2037/

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

  Dan.