Re: [TLS] JPAKE

2016-02-15 Thread Brian Smith
Robert Cragie wrote: > I was told it wouldn't receive much interest because it is based on TLS > 1.2 and the current focus is very much on 1.3. The aim is to get an > informational RFC out shortly. > I'm looking forward to the RFC and I would be happy to offer

Re: [TLS] JPAKE

2016-02-15 Thread Watson Ladd
On Feb 15, 2016 11:02 AM, "Brian Smith" wrote: > > Robert Cragie wrote: >> >> I was told it wouldn't receive much interest because it is based on TLS 1.2 and the current focus is very much on 1.3. The aim is to get an informational RFC out

Re: [TLS] JPAKE

2016-02-15 Thread Tony Arcieri
On Mon, Feb 15, 2016 at 11:54 AM, Watson Ladd wrote: > PAKE in SSL has always been a solution in search of a problem. > Browsers do not have UI elements compatible with PAKE (unless someone cares to bring up the basic auth dialog, in which case I'd simply suggest please

Re: [TLS] JPAKE

2016-02-15 Thread Robert Cragie
The big assumption here is that SSL/TLS is used solely in browsers. That is not how it is being used in Thread, for example, and indeed in other similar technologies. In Thread, it is used for local device authentication and authorisation. These use cases clearly benefit from a PAKE, i.e. getting

Re: [TLS] JPAKE

2016-02-15 Thread Tony Arcieri
On Mon, Feb 15, 2016 at 4:33 PM, Robert Cragie wrote: > The big assumption here is that SSL/TLS is used solely in browsers. > In literally every one of the non-browser SSL/TLS contexts I use today, I do not use passwords (preferring client certs instead). The main