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

From: "Dan Harkins" <[email-masked]>
Date: Mon, 18 Jul 2016 03:06:26 -0700 (PDT)

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Watson Ladd <[email-masked]>
Date: Mon, 18 Jul 2016 07:09:16 -0700

> or it's the only thing used and that makes it sort of a proprietary

This stems from the multiple rounds used in JPAKE. SPAKE2 uses only 2
rounds, and would be easier to put into TLS. I'm still working on the
draft, but haven't gotten to it in a while.

Sincerely,
Watson

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Robert Cragie <[email-masked]>
Date: Tue, 19 Jul 2016 20:55:09 +0100

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

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 20 Jul 2016 03:17:46 -0700 (PDT)

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:
>> > * The draft is based on TLS/DTLS 1.2 as the Thread group required
>> basis
>> on

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 20 Jul 2016 11:14:47 +0000

So Dan,

If your reasoning is correct, it seems like an individual submission "using TLS for ECJ-PAKE" seems more appropriate than a TLS WG document or any codepoint assignment (since as you say they can use the private-use one).

	/r$ 

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Feng Hao <[email-masked]>
Date: Wed, 20 Jul 2016 15:13:56 +0000

Hi Dan,

On your first comment, Yes, J-PAKE requires one more flow, but for the following benefits

 * Unlike EKE and SRP, it has the flexibility to work in any prime-order subgroup over a finite field (e.g., DSA-like groups). 
 * Unlike SPAKE2, it doesn't require setting up two generators whose discrete logarithm must be unknown. The design of J-PAKE is to let end users have the complete control of the randomness (by generating two ephemeral public keys which are random and unrelated) rather than trusting an external party to set the randomness in the group parameters.
 * Unlike Dragonfly, it doesn't require any hashing-to-curve function. It merely needs a curve, a base point and +/* operations. Hence, it can be easily applied to any EC curve that is suitable for cryptography (as long as the DDH assumption holds).

On your second comment, is there any fundamental reason why the first flow (client hello) can't contain key exchange messages? Kindly note that:

 * The proposed PAKE usage is not meant for web browsers (for reasons explained in the draft). But TLS should be useful for applications other than just web browsers. 
 * In a non-browser setting for realizing secure communication between two remote parties and considering the fact that J-PAKE is a balanced PAKE (same as Dragonfly), it seems sensible to let client initiate the choice of ciphersuit and see if the server supports it (here, I use client and server for convenience, but they are more like peers with equal say).

Cheers,
Feng

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Dan Harkins
Sent: 20 July 2016 11:18
To: Robert Cragie <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Comments on TLS-ECJ-PAKE draft

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

as opposed to:

  - figure 1 in

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