Re: [Allseen-core] [AllSeen Alliance TSC] Deprecation (and replacement) of ECDHE_PSK

Thu, 25 Feb 2016 12:09:12 -0800

Adding Brian in the "to" list.  Brian, has the Security Subcommittee reviewed Greg's ECDHE_SPEKE proposal? Given how important this new change is, and that is departs somewhat from IEEE 1363.2 (as Greg explains in his spec document) it seems like an independent review of the new security mode would be in order by the SSC?

Thanks, Art


Affinegy

Art Lancaster, CTO
Affinegy
1705 S. Capital of Texas Hwy, Ste. 310, Austin, TX, 78746
O 512.535.1700 x1010 | M 512.848.0818

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient(s), please contact the sender by reply e-mail and destroy all copies of the original message.

On 2/25/16 1:31 PM, Greg Zaverucha wrote:

Josh: In a security 2.0 deployment, PSK is only used for onboarding/claiming. In a security 1.0 deployment apps could choose to use it however they want.

 

Ken: deprecation will follow the regular AllJoyn deprecation process.  Here’s my understanding of the timeline: PSK will be annotated as deprecated in 16.04.  It will be supported for two releases, then still present but unsupported for another two.

 

Greg

 

From: Josh Spain [mailto:[email protected]]
Sent: Thursday, February 25, 2016 11:22 AM
To: Swinson, Ken <[email protected]>
Cc: Lioy, Marcello <[email protected]>; Greg Zaverucha <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: [Allseen-core] [AllSeen Alliance TSC] Deprecation (and replacement) of ECDHE_PSK

 

Greg,

 

Can you describe the scenarios other than during onboarding in which ECDHE_PSK is currently or would potentially be used in AllJoyn?

 

Thanks,

Josh

 

On Thu, Feb 25, 2016 at 8:59 AM, Swinson, Ken <[email protected]> wrote:

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]] On Behalf Of Greg Zaverucha
Sent: Thursday, December 03, 2015 2:23 PM
To: [email protected]; [email protected]; [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

 



_______________________________________________
Allseen-core mailing list
[email protected]
https://lists.allseenalliance.org/mailman/listinfo/allseen-core




_______________________________________________
Allseen-core mailing list
[email protected]
https://lists.allseenalliance.org/mailman/listinfo/allseen-core

Reply via email to