RE: I want to have unsafe key exchange.

Vijay, Ryan, and all,

Just to make sure we are on line on this topic :
About a key to be extractable, Ryan wrote" it is up to the implementation and how it handles key", my understanding of our conversations was that this 'extractable capability' should be defined at key creation. If it is really up to the implementation and will vary from one browser to another, then I think we do not help the developer to build consistent security : he will not be able to choose if the key could or not be viewed by the JS.
Did I miss something ?

Regards,
Virginie



From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: lundi 2 juillet 2012 20:53
To: Vijay Bharadwaj
Cc: Eric Rescorla; Wan-Teh Chang; David Dahl; Zooko Wilcox-OHearn; public-webcrypto@w3.org
Subject: Re: I want to have unsafe key exchange.


On Sat, Jun 30, 2012 at 12:11 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
I'd like to advocate for not requiring the raw shared secret to be accessible to apps.

I don't think it's required that the raw key be extractable - for exactly the reason that you specified.

However, it may be extractable - it's up to the implementation and how it handles secrets. I think this is true independent of any discussion of secure elements - simply whether or not javascript content can/should be exposed to raw keys.

Part of my goal is wanting to provide a useful API that provides a facility that, even if the browser doesn't implement (insert esoteric algorithm here), the application can route around it - either by utilizing a different algorithm (via discovery) or by implementing an algorithm in content (which requires raw access). Every new "standard" first starts off as something esoteric, and then is eventually implemented wide enough that it could rightly be considered standard.

Since the web platform still has to contend with legacy devices, and will inevitably have to consider constrained devices as well, I want to make sure that content always has the possibility to gracefully degrade the experience, even as standards and technologies (such as DH + some KDF here) change.


Many crypto modules (often for FIPS and other certification purposes) only expose the key agreement primitive (i.e. DH operation + a KDF) and do not expose a raw DH primitive. For the specific case of ZRTP, this would appear to be enough - ZRTP appears to be doing an SP800-56A key agreement (i.e. DH + SP 800-56A KDF) followed by another KDF (i.e. SP 800-108 KDF). This is achievable as long as we provide a KDF primitive. I do agree we must provide a facility for importing raw keys if we want to support any form of DH (as others have noted).

I realize raw DH is useful in various places; but it's arguable that it is similar to mod-exp - a math-level primitive which is not essential to a crypto-level API.

-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com<mailto:ekr@rtfm.com>]
Sent: Monday, June 18, 2012 12:41 PM
To: Wan-Teh Chang
Cc: Ryan Sleevi; David Dahl; Zooko Wilcox-OHearn; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: Re: I want to have unsafe key exchange.
On Mon, Jun 18, 2012 at 11:34 AM, Wan-Teh Chang <wtc@google.com<mailto:wtc@google.com>> wrote:
> I think we should provide the commonly used key derivation functions
> to reduce application mistakes.  But I find Zooko's challenge of
> implementing ZRTP very thought-provoking.  Since the key derivation
> function of ZRTP doesn't seem to be a common one, I believe that a web
> browser will need to export the raw shared secret either in native
> code or in JavaScript.  (I don't know of a native crypto API that
> allows a caller to provide an arbitrary key derivation function.)

I don't believe that this can be done without effectively allowing the application to extract the secret input if it chooses to.

I.e., this is a cut point between two models of key isolation:

(1) reduce application screwups by making it hard to access the key
(2) protect against malicious applications accessing the key.


-Ekr