Re: I want to have unsafe key exchange.

On Sat, Jun 30, 2012 at 12:11 AM, Vijay Bharadwaj <
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]
> Sent: Monday, June 18, 2012 12:41 PM
> To: Wan-Teh Chang
> Cc: Ryan Sleevi; David Dahl; Zooko Wilcox-OHearn; 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> 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
>
>
>