Re: I want to have unsafe key exchange.

David,

I must say, your response surprises me. I was under the impression that
just two weeks ago, you were advocating that the keying material always be
available.

Perhaps you're talking from the perspective of a high-level API, and I'm
thinking from the low-level API?

Further responses inline.

On Thu, Jun 14, 2012 at 8:50 AM, David Dahl <ddahl@mozilla.com> wrote:

>
>
> ----- Original Message -----
> > From: "Zooko Wilcox-OHearn" <zooko@leastauthority.com>
> > To: public-webcrypto@w3.org
> > Sent: Thursday, June 14, 2012 9:44:42 AM
> > Subject: I want to have unsafe key exchange.
> >
> >
> <snip>
> > So, I don't really understand whether all the discussion of
> > protecting
> > keys and identifying them by key IDs means that the uses I envision
> > --
> > unprotected keys -- will be unsupported.
> >
>
> Initially, I think this was not a use case that was in mind for the API.
> However, we have discussed a few operations where this would be required to
> support specific protocols. I think in most cases, we would not want
> developers using this kind of 'the footgun is loaded' operation.
>

In my view, this has been a core requirement for the API, so I'm surprised
that you see it out of scope. This was also part of the discussion with ekr
about 'safe' operations.

I see no reason to require that the API MUST NOT be able to expose the
keying material. I also see no reason to require that the MUST expose the
keying material. I think the API MAY expose key material, and that it's
dependent on externalities (eg: how the  app created the key, how/where the
key is stored, any relevant security properties the browser imposes, etc).


>
> > Will the spec require implementers to offer an API to extract the
> > complete bytes of a private key or symmetric key, and to create a
> > private key or symmetric key from a string of bytes?
> >
>
> As far as symmetric keys are concerned, I have been thinking we would spec
> out a wrapped key object, with the unwrapping happening out of the content
> JS scope. With a compelling use-case I can see an API that allows raw key
> material to be generated that is perhaps not persisted and not given any
> kind of ID. Would that satisfy your usage?
>

I think this is a MUST requirement. Otherwise, the use of a DHE exchange to
negotiate some keying material seems... not at all useful.

Wrapped keys are only useful if you have a wrapping key. How do you
import/export the wrapping key? For exchange between peers? Between
browsers?

In practice, requiring key wrapping tends to heavily dilute the 'actual'
value of the API, and in practice (eg: see the PKCS#11 attack papers
previously referenced) may offer little-to-no added security.

That isn't to say I think key wrapping is useless, simply that it shouldn't
be mandatory.


>
> Do you have a use case written down for this kind of operation?
>
> David
>
>