I can confirm the Thread Group is using an EC variant of JPAKE, which we
have been using in interop tests for over a year now. I have had a short
presentation ready to give to TLS WG for some time but I was told it
wouldn't receive much interest because it is based on TLS 1.2 and the
current focus
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 d
A few points to some of the comments:
1) Thread devices are not typically smartphones and PCs. They are class 1
constrained devices according to RFC7228, i.e. thermostats and light
switches etc.
2) Device certs. and short fingerprints are indeed used in similar systems
to Thread (e.g. ZigBee IP)
3
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 possi
e 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 T
The original requirement for the truncated (_8) authentication tags was
purely to save bytes. It makes very little difference re. processing as a
16 octet tag is always computed in AES-CCM-128 anyway.
I agree with the assessment that it is "limited applicability" in the grand
scheme of things alth
