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

"Dan Harkins" <dharkins@lounge.org> Wed, 20 July 2016 10:18 UTC

Return-Path: <dharkins@lounge.org>
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 1151E12DB09 for <tls@ietfa.amsl.com>; Wed, 20 Jul 2016 03:18:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 UVuDGbVRFboJ for <tls@ietfa.amsl.com>; Wed, 20 Jul 2016 03:17:57 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id DDF8612DB38 for <tls@ietf.org>; Wed, 20 Jul 2016 03:17:46 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4E9BE1FE0240; Wed, 20 Jul 2016 03:17:46 -0700 (PDT)
Received: from 31.133.162.219 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 20 Jul 2016 03:17:46 -0700 (PDT)
Message-ID: <2ee1801e4404fd17c2a1694ac12f79d3.squirrel@www.trepanning.net>
In-Reply-To: <CADrU+dL6e-kou3QDmYZpseXkBYzPF4haLOmUzoZzNBw5Z-XivQ@mail.gmail.com>
References: <CADrU+d+V3MNuUPp-FmJopS=SRn5Zp673758i5Y+Sg4qP+gUaMA@mail.gmail.com> <52173e33a5b14592b16ac6b6eae8fe81.squirrel@www.trepanning.net> <CADrU+dL6e-kou3QDmYZpseXkBYzPF4haLOmUzoZzNBw5Z-XivQ@mail.gmail.com>
Date: Wed, 20 Jul 2016 03:17:46 -0700 (PDT)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Robert Cragie" <robert.cragie@gmail.com>
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/eaZcmZyH-SI_-jWrTmNhnLwWi6U>
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: Wed, 20 Jul 2016 10:18:00 -0000

  Hi Robert,

  Sorry for the confusing comments. There are 2 but one follows
because of the other.

  The first comment concerns the fact that J-PAKE is a 4 message
handshake. This is different than other PAKES like EKE, SPAKE2,
dragonfly, or SRP which all establish their shared key in a single
2 message exchange. A 2 message exchange falls into the TLS handshake
elegantly, e.g.:

  - figure 1 in https://tools.ietf.org/html/rfc5054#page-5
and
  - figure 1 in https://tools.ietf.org/html/draft-ietf-tls-pwd-07#page-10

as opposed to:

  - figure 1 in
https://tools.ietf.org/html/draft-cragie-tls-ecjpake-00#page-7

where as you are making the TLS "Hello phase" into a "Hello plus
one-half of the key exchange phase". This is my comment about this
being a fundamental change to TLS.

  Now the 2nd comment that follows out of the 1st is that by
overloading the Hello Phase to include half the key exchange phase
you remove all ability to do negotiation. When TLS-ECJ-PAKE is
used it is the only thing that can be used. The client can only
offer it and it can only talk to servers that support it. Which
is why my 2nd comment is that this is fundamentally a proprietary
protocol. You don't need a cipher suite assignment for this because
you have no ability to negotiate it. You could make it 0xFF,0xFC-FF
(reserved for private use) and have no issues. You will never
have interop issues with some other TLS-like private protocol
that also uses 0xFF,0xFC-FF because you'll never talk to them. Your
TLS-ECJ-PAKE client always and only talks to your TLS-ECJ-PAKE
server so your private assignment of the private use cipher suites
cannot conflict with any other private assignment. Proprietary
protocols don't need cipher suite assignments and this is a
proprietary extension of TLS.

  regards,

  Dan.

On Tue, July 19, 2016 12:55 pm, Robert Cragie wrote:
> 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
>> >
>>
>>
>>
>