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]
> <[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

Reply via email to