We discussed the planned deprecation of ECDHE_PSK on an HAE working group call this AM. A concern was raised regarding how quickly ECDHE_PSK will be deprecated. I recall from the core working group calls that there is a desire to deprecate this feature quickly once this new authentication method is added.
The concern raised by HAE group is that they are launching their service frameworks on core 15.09 and will be using ECDHE_PSK for authentication. They need to plan a transition to the new method while supporting released products using ECDHE_PSK. I looked for and did not find a jira ticket tracking the deprecation of ECDHE_PSK. Is there one? From: [email protected] [mailto:[email protected]] On Behalf Of Lioy, Marcello Sent: Thursday, December 10, 2015 2:58 PM To: Greg Zaverucha; [email protected]; [email protected]; [email protected] Subject: Re: [AllSeen Alliance TSC] Deprecation (and replacement) of ECDHE_PSK As there has been no responses to this the Working Group decided in the call today to in fact deprecate this authentication mechanism. Thanks to Greg for driving the proves and volunteering to do the work. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Greg Zaverucha Sent: Thursday, December 03, 2015 2:23 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [Allseen-core] Deprecation (and replacement) of ECDHE_PSK The core working group discussed today whether to mark ECDHE_PSK as deprecated in 16.04, and have a new mechanism called ECDHE_SPEKE replace it. Information about the new mechanism is here: https://jira.allseenalliance.org/browse/ASACORE-2055 . The main difference between SPEKE and PSK is that SPEKE is secure even when the pre-shared secret is a low-entropy password, while for PSK the peers must share a key with high entropy (ideally, 128 bits). The reasons for deprecation are - There is no use case that ECDHE_PSK addresses that ECDHE_SPEKE doesn't. The primary use case for PSK in Security 2.0 is onboarding, and SPEKE is appropriate for this use case. - ECDHE_PSK is easy to misuse, if an app uses a short password instead of a high entropy key, security is lost. - Having two ways to do similar things causes confusion, complicates the code (and increases TC memory footprint) Consensus on the call was to go ahead with deprecation, this email is to give those that weren't on the call a chance to weigh in. We'll finalize the decision on the core WG call next Thursday (Dec. 10th). If you have concerns about this change, please voice them before then. Greg
_______________________________________________ Allseen-core mailing list [email protected] https://lists.allseenalliance.org/mailman/listinfo/allseen-core
