On Tue, February 16, 2016 8:34 pm, Tony Arcieri wrote: > On Mon, Feb 15, 2016 at 4:33 PM, Robert Cragie > <robert.cra...@gridmerge.com> > wrote: > >> In Thread, it is used for local device authentication and authorisation. >> These use cases clearly benefit from a PAKE, i.e. getting deriving a >> shared >> cryptographic from a weaker shared password. >> > > The better way to solve this problem is a device-specific "keychain", > which > possibly loops in some sort of secure enclave for decrypting secrets, and > can authorize secret decryption based on the requesting app, derive a > strong master secret from a weak password/pin (possibly using a PUF for > anti-tamper). This is becoming a standard feature of the OSes on most > devices humans actually physically interact with, e.g. most smartphones, > tablets, and any OS you'd find on a laptop.
What?!? How is that "better"? Having a "keychain" that loops in some vague "secure enclave" that makes authorization decisions based on some app deriving a "strong master secret from a weak password/pin" sounds complicated, has more moving parts and more possibility of things going wrong. If there's some password/pin involved then the protocol should not depend on whether it's weak or not. Period. That means PAKE. Regarding JPAKE, it's support in OpenSSL is in the apps directory, not the ssl directory. That is, there is no TLS ciphersuite that supports it and that means no app can use it (except through system() calls or some such ugliness). TLS-pwd is defined as a TLS ciphersuite though. Dan. > If you have this sort of keychain system, you can provision secrets > on-the-fly, e.g. origin-bound certificates. Now you don't need PAKE. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
