Re: [TLS] Comments on TLS-ECJ-PAKE draft

Robert Cragie <robert.cragie@gmail.com> Tue, 19 July 2016 19:55 UTC

Return-Path: <robert.cragie@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788F212D1B3 for <tls@ietfa.amsl.com>; Tue, 19 Jul 2016 12:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 QPnKcpnFRW-l for <tls@ietfa.amsl.com>; Tue, 19 Jul 2016 12:55:12 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2243212D7A4 for <tls@ietf.org>; Tue, 19 Jul 2016 12:55:11 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id o80so39593459wme.1 for <tls@ietf.org>; Tue, 19 Jul 2016 12:55:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E/TJXeHDfZ279AmWGLZI90vOGQ7qD4n1ZR7hNPUL6nU=; b=N/Nu2YNI9zbUSDDqe23mHHifGgGLefjKlVWP6G9GFLmHY47F+8lqTQ8FmiyXaFnJ0a Sc09HVPAMijTvjPxdfd7jv8ciOLyiuiMaXhyTthzY/eD/YfK2vJxbEEPTYoaI3LyWzA5 CsfmlE/d8iHHNfKhAGqfE27MaIfysZC2Z0EY1TGlNYb2Kvjg1Kyh0raCnjYZA/Hd518P rWsSRFaeBm/UGfmaf0yQ1NxRwMHVRnCjG03JT6pkICoeYid3oAV52w1V9kAxLMm7GFlz xXPxg0GBjEoUkl7A5Vs8BOCzOrNcGnQlmYrepc1lhMSVJGI+O2is60e30bt2dYoGRjc1 RgBA==
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:from:date :message-id:subject:to:cc; bh=E/TJXeHDfZ279AmWGLZI90vOGQ7qD4n1ZR7hNPUL6nU=; b=gpJj5M/sPNFCbBLP1FjaPUEedBvNKPK/CLSNvfZ7uvdeE4jX7T/uy4rjbWgWO2UYWt m8LtzMn4pAYbOOEEg6VDMVK6rVeT74HX+8EW8ZT2DuBHJlpaei+mXNtVwaAlV2BRjMej mkjYIrCLM4NdkrJS5RdN7PPrUmeeN/QPkmPlpDIMQMLcRi/AAhaasFc6rNP/o9Maf1B0 OCO/D9ZxYunojNx77jAeZjdzHqbZLljPZpiy2ipTQF33JoQKSPsW+bKOeDd5SnlI14vP uu182UQ1vQJoXbpu7yWBH7ybO4rMtOgYF9yVNWx18ZaL/BqHO11dBkY1T6bFcYSK4cuQ 5X2Q==
X-Gm-Message-State: ALyK8tIxTdz1/QKyDaY6s6838aqWvHuzqiEAI8aGwDfxuHMogL0Vi7R9CDOOLo4gYCA8hTufp3NblStEfDe1ig==
X-Received: by 10.28.232.145 with SMTP id f17mr6310981wmi.15.1468958109583; Tue, 19 Jul 2016 12:55:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.83.99 with HTTP; Tue, 19 Jul 2016 12:55:09 -0700 (PDT)
In-Reply-To: <52173e33a5b14592b16ac6b6eae8fe81.squirrel@www.trepanning.net>
References: <CADrU+d+V3MNuUPp-FmJopS=SRn5Zp673758i5Y+Sg4qP+gUaMA@mail.gmail.com> <52173e33a5b14592b16ac6b6eae8fe81.squirrel@www.trepanning.net>
From: Robert Cragie <robert.cragie@gmail.com>
Date: Tue, 19 Jul 2016 20:55:09 +0100
Message-ID: <CADrU+dL6e-kou3QDmYZpseXkBYzPF4haLOmUzoZzNBw5Z-XivQ@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: multipart/alternative; boundary=001a11466d9a5001a10538027610
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/37h8L4trXhFrAJabdTfX4z1c_wg>
X-Mailman-Approved-At: Wed, 20 Jul 2016 00:52:00 -0700
Cc: tls@ietf.org
Subject: Re: [TLS] Comments on TLS-ECJ-PAKE draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 19 Jul 2016 19:55:14 -0000

Hi Dan,

What you say regarding the NamedCurve/EllipticCurveList is of course right.
Whether this constitutes a fundamental change to TLS is debatable. The aim
was never to propose this as a cipher suite for general inclusion in a
range of supported cipher suites in a browser/server scenario as is pointed
out in various places in the draft. The aim was to reuse TLS (a well-known
and widely implemented protocol) as a vehicle to support the ECJ-PAKE
method and to deliberately constrain the implementation parameters a
priori. To me, that does not make this a proprietary protocol and the ease
by which existing TLS implementations have been adapted to support
TLS-ECJ-PAKE. I guess it does raise the wider question of "what is TLS"
though and whether this approach flouts conventional thinking about TLS
(which, IMHO, it doesn't).

Robert

On 18 July 2016 at 11:06, Dan Harkins <dharkins@lounge.org>; wrote:

>
>   Hi Robert,
>
>   This draft moves the NamedCurve/EllipticCurveList into the
> ClientHello, and since the client sends X1 and ZKP(X1) in the
> ClientHello it means that is going to be a list of 1. It basically
> moves the client's key exchange portion from ClientKeyExchange into
> ClientHello. So basically, if a client wants to do TLS-ECJ-PAKE
> then that's the only thing it can offer and the parameters of
> that exchange are all selected by the client, not the server.
>
>   This is a fundamental change to TLS. If it's going to be offered,
> it's the only thing that can be offered and therefore the only thing
> that can be used. Seems like for a deployment either it's never used
> or it's the only thing used and that makes it sort of a proprietary
> protocol, not TLS.
>
>   Dan.
>
> On Thu, June 16, 2016 2:51 am, Robert Cragie wrote:
> > I would like to ask the working group for comments on the TLS-ECJ-PAKE
> > draft:
> >
> > https://tools.ietf.org/html/draft-cragie-tls-ecjpake-00
> >
> > Some brief notes:
> >
> > * This intended status is informational.
> > * The draft is based on TLS/DTLS 1.2 as the Thread group required basis
> on
> > existing RFCs wherever possible. For that reason and due to the WGs focus
> > on TLS 1.3, I have understood from the chairs that it would not have
> > received a great deal of attention from the WG, hence the intended status
> > of informational.
> > * The draft reflects the current use of the
> TLS_ECJPAKE_WITH_AES_128_CCM_8
> > cipher suite in Thread (http://threadgroup.org/).
> > * There is an experimental implementation in mbed TLS (
> > https://github.com/ARMmbed/mbedtls)
> > * The Thread group would like to get IANA assignments for 4 cipher suite
> > values and one ExtensionType value as soon as possible.
> > * There are at least four independent implementations, which have been
> > used
> > in interop. testing over the last 18 months.
> > * The security considerations recommend restriction of the use of this
> > cipher suite to Thread and similar applications and recommends it should
> > not be used with web browsers and servers (mainly due to the long
> > discussions regarding the use of PAKEs on this and other mailing lists).
> >
> > Robert
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
>
>