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

SeongHan Shin <seonghan.shin@aist.go.jp> Fri, 06 December 2013 01:22 UTC

Return-Path: <seonghan.shin@aist.go.jp>
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 63F2F1AE26C for <tls@ietfa.amsl.com>; Thu, 5 Dec 2013 17:22:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.678
X-Spam-Level:
X-Spam-Status: No, score=-3.678 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_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 9WX_fGzngDDh for <tls@ietfa.amsl.com>; Thu, 5 Dec 2013 17:22:08 -0800 (PST)
Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with ESMTP id 4D96A1AE267 for <tls@ietf.org>; Thu, 5 Dec 2013 17:22:08 -0800 (PST)
Received: from mail-ie0-f174.google.com ([209.85.223.174]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKUqEmvEX+1gQhidxyBjGe1wrgy2Ch8NvX@postini.com; Thu, 05 Dec 2013 17:22:05 PST
Received: by mail-ie0-f174.google.com with SMTP id at1so70411iec.19 for <tls@ietf.org>; Thu, 05 Dec 2013 17:22:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K+xkC9aEAmWyKtZZgCWX35LwKzxDCt4ijgSuU/R5xPU=; b=LQaRnICpk682J3kDqqH7N46J4omeOrN3EPUDsMiaX+QqD+qBI1j72XIm8vF2zz4D9Q qUJpZctSIQhJxyhPQxg7NpMf8hdBA1V9q2BNZBXSf5sDxjBbmqiHQTaTW3wwVkVuCeHC YpeLZwh2b4Q/M7z4UmfrbVf5Jrh6bA8fx6kto=
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=K+xkC9aEAmWyKtZZgCWX35LwKzxDCt4ijgSuU/R5xPU=; b=hH2EydQxjCpUGH0S4GvVCLC7Ti5yBRW7CZZFnUos3UT8UxWSY55oj98hniIvZzJOVU gvpaYl9nyBcjJPHuJvwgPgDfz/HDeJpNtKx7WMINLpV7k+16YgeC7NkevA4BwB7LeeCj YYqphBgNSVdhWuG+XS4X78QZVu7dVuLP5LwCG2NN4Lr6zdqeYIoy/N9Ja78afYrptRKO cu93HdfMxU2RZVnH/cS2tcAoX2j+wifECwPLN5jd8/GtSBlgq15hYdsAaUCSJs5DWlYN rl8OimQVpqqW4cXexExFfs0RayNvH7695mGHV3KX3ogqJecsLU8GyOZNipfkHH0/SUyF 3w2w==
X-Gm-Message-State: ALoCoQnSv1v5S6iqL6xS9bpu4jj9/ZwimOxCZgPYmRx5K5syowuaPHd9vHXKqmkiaH9DhVKhF9QIkNdXjs+CuiINGD5R8DG9wYtRNWl4FzVnsRkUDT685d7sJGgs/QLxMYbUCTsIuTF2WGyqvfusjShFh3Sa0v6x6Q==
X-Received: by 10.50.16.68 with SMTP id e4mr141823igd.12.1386292924450; Thu, 05 Dec 2013 17:22:04 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.16.68 with SMTP id e4mr141810igd.12.1386292924273; Thu, 05 Dec 2013 17:22:04 -0800 (PST)
Received: by 10.50.119.226 with HTTP; Thu, 5 Dec 2013 17:22:04 -0800 (PST)
In-Reply-To: <7c8448fa356f5d764186ca62552efb1d.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> <CAGZ8ZG0n7AFWc_WpxLzKbhnRxz8hkQAD-j8VDtX_GOHD5Nc6nw@mail.gmail.com> <7c8448fa356f5d764186ca62552efb1d.squirrel@www.trepanning.net>
Date: Fri, 6 Dec 2013 10:22:04 +0900
Message-ID: <CAEKgtqkxdYMXDNEMWGO=S1ayYuFQV3REkUJXy9vjBE4bCW_5bg@mail.gmail.com>
From: SeongHan Shin <seonghan.shin@aist.go.jp>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=047d7bdca30a4e6ca504ecd379ed
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: Fri, 06 Dec 2013 01:22:11 -0000

Dear all,

>> 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/<https://datatracker.ietf.org/ipr/2037/>

As in the above IPR Disclosures, AugPAKE can be used royal-free for any
conforming implementations.
The patent of AugPAKE was granted in Feb. and April of 2013 from Japan and
U.S. respectively.

Best regards,
Shin


On Fri, Dec 6, 2013 at 3:40 AM, Dan Harkins <dharkins@lounge.org> wrote:

>
>
> 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.
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
------------------------------------------------------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------