Re: Non-extratability Tainting of Keys

On Mon, Sep 9, 2013 at 3:45 PM, Jim Schaad <ietf@augustcellars.com> wrote:

> Ok – I remember that as being discussed, but I did not think it was on the
> table as a solution and I believe that this is not a solution that solves
> the Netflix problem.****
>
> ** **
>
> The problem statement that I believe that Netflix has is:
>

I would prefer Mark ask for this.

Is this something you have a concrete use case for? If so, I would much
rather prefer to discuss is separate from the Netflix case, so that we do
not conflate nor misrepresent requirements.


> ****
>
> ** **
>
> It is required that one can chain from one non-extractable key (KeyA) to a
> second non-extractable key (KeyB) in such a way as to prevent an active
> script attacker from obtaining the value of KeyB while being able to use
> KeyA for “normal” purposes.****
>
> ** **
>
> The solution of having an attribute in a JWK fails for the following
> reasons:****
>
> ** **
>
> **1.       ** You may not be able to wrap a JWK in an RSA key due to size
> constraints.  This solution only works if you are assuming that KeyA is a
> symmetric key and not if it is an asymmetric key (either RSA or ECDH).
>
Which is sufficient for the Netflix case.

****
>
> **2.       **If the active script can capture the encrypted JWK which is
> being passed from the server to the client, then it can call the decrypt
> function on KeyA to decrypt the JWK and then parse the JWK to get KeyB
> independent of the presence of an attribute in the JWK string.
>

That's why we have distinct wrap and decrypt usages. This is not possible.

Regardless, however, active network attackers MUST be out of scope. In my
mind, it is an explicit NON-GOAL to try to provide *continued* robustness
in the presence of active script injection.

There has yet to be a use case where this threat model is actually
something that makes sense in the web security model, which is why I have a
hard time with this. Next thing you know, we'll be trying to prevent
against persistent XSS, another non-goal.

If the issue you're trying to solve is a hostile network adversary, use TLS.
If the issue you're trying to solve is a hostile party achieving XSS, use
CSP.
If the issue you're trying to solve is a hostile local user, you're not
going to solve that problem.

> ****
>
> ** **
>
> Jim****
>
> ** **
>
> ** **
>
> *From:* Ryan Sleevi [mailto:sleevi@google.com]
> *Sent:* Monday, September 09, 2013 11:57 AM
>
> *To:* Jim Schaad
> *Cc:* public-webcrypto@w3.org
> *Subject:* Re: Non-extratability Tainting of Keys****
>
> ** **
>
> ** **
>
> ** **
>
> On Sat, Sep 7, 2013 at 7:17 PM, Jim Schaad <ietf@augustcellars.com> wrote:
> ****
>
> If there is a solution to the non-extractability on the table, I have
> completely missed it.****
>
>  ****
>
> I was unable to come up with a good solution to the non-extractability
> problem that was not as draconian as the one that I proposed except for
> some very limited cases.  I would love to get a pointer to the Netflix
> solution so that I can see if I think it really works or if it is just a
> very small subset of what is needed.  Does the solution work just for the
> RSA key transport problem or does it work for the ECDH problem as well?***
> *
>
>  ****
>
> Jim****
>
>  ****
>
> ** **
>
> The Netflix solution: Only applies to JWK, through the introduction of a
> new attribute. Any JWKs unwrapped with this attribute supercede the
> attributes specified by the caller.****
>
> ** **
>
> My proposal: unextractability is specified by the caller.****
>
> ** **
>
> It's extremely important that you elaborate on your threat model when
> unwrapping keys as well as your expectations on what 'unextractable' means.
> In the discussions so far, it's in the context of "key provisioning", which
> is such a complex can of worms (see Anders' proposals to understand just
> *some* of what is commonly requested) that I would much rather not try to
> boil the ocean to solve that yet, and I'm convinced that the current
> Netflix proposal is NOT something that is web-extendable in the future when
> we DO try to solve those.****
>
> ** **
>
>  ****
>
>  ****
>
> *From:* Ryan Sleevi [mailto:sleevi@google.com]
> *Sent:* Friday, September 06, 2013 4:55 PM****
>
>
> *To:* Jim Schaad
> *Cc:* public-webcrypto@w3.org
> *Subject:* Re: Non-extratability Tainting of Keys****
>
>  ****
>
> Jim,****
>
>  ****
>
> Could you state then what problem you're trying to solve?****
>
>  ****
>
> We have solutions for non-extractability on the table. You've proposed yet
> another. The question is what set of problems you believe they solve that
> the other solutions do not solve or solve inadequately that required yet
> another proposal.****
>
>  ****
>
> That is, you enumerated your proposal, highlighting a number of
> disadvantages compared to any of the existing proposals, but unless I'm
> mistaken, you failed to highlight what (new) problems were being solved.**
> **
>
>  ****
>
> Given that Netflix has proposed at least one solution that they feel meets
> their needs in a much less restrictive manner, I'm curious what problem
> space you feel needs an even more restrictive API space (eg: one that
> prevents polyfills).****
>
>  ****
>
> Cheers****
>
>  ****
>
> On Fri, Sep 6, 2013 at 4:50 PM, Jim Schaad <ietf@augustcellars.com> wrote:
> ****
>
> I believe this is something that I desire.  I believe that this is
> probably what Nexflix desires.****
>
>  ****
>
> I believe that this is not going to make Ryan think that this is a problem
> that needs to be solved.****
>
>  ****
>
> Jim****
>
>  ****
>
>  ****
>
> *From:* Ryan Sleevi [mailto:sleevi@google.com]
> *Sent:* Friday, September 06, 2013 4:20 PM
> *To:* Jim Schaad
> *Cc:* public-webcrypto@w3.org
> *Subject:* Re: Non-extratability Tainting of Keys****
>
>  ****
>
>  ****
>
>  ****
>
> On Fri, Sep 6, 2013 at 3:41 PM, Jim Schaad <ietf@augustcellars.com> wrote:
> ****
>
> This is a proposal of how to do tainting of keys with non-extractability.
>   As part of this proposal, there is a set of things that are restricted
> when you have a key marked as non-extractable.  I do not believe that these
> restrictions are burdensome, but others might.  This message is intended to
> provide a workable solution to the non-extractible problem.  There is still
> a need to determine if this work is needed or not.
>
> My assumption is that when one starts with a non-extractable secret, then
> all secrets that are derived from that secret need to be non-extractable as
> well.****
>
>  ****
>
> That's not something I desire. Is that something you desire, or is this an
> interpretation of what Netflix desires?****
>
>  ****
>
> I guess I read your preamble as "I'm not sure what problem I'm trying to
> solve, but here's a possible solution", which leaves me a bit... confused?
> ****
>
>  ****
>
>
> Changes to the current document:
>
> 1.  There is a new restriction placed on algorithm descriptions so that
> the usages [KeyWrap,KeyUnwrap] and [Encryption,Decryption] are mutually
> exclusive.   Most of the time this will not be an issue, but for some
> encryption algorithms it will mean that there will need to be two
> algorithms defined.  One of these will be for content encryption and one
> will be for key encryption.  This would be an issue for example with
> AES-GCM where a new AES-GCM-KeyWrap algorithm would need to be defined
> which allows for key wrapping to occur.
>
> 2.  When a key agreement operation is done with a key marked as
> non-extractable, the DeriveBits key usage is removed on the resulting
> secret so that only keys can be derived.
>
> 3.  KeyUnwrap, KeyAgreement and DeriveKey all propagate the
> non-extractable bit if it is on the key that was used in the operation.
>
> 4.  It is assumed that a key encryption algorithm which unwraps a key
> produces a content encryption key (i.e. the usage on the resulting key is
> decryption not key unwrap). If one wants to do a two level key unwrap then
> a new algorithm would need to be defined that went from a key wrap key to a
> key wrap key rather than a content encryption key.  I would be surprised if
> this was ever needed in practice.
>
> The resulting restrictions:
>
> 1.  Only the algorithms defined in the UA will be available to a
> non-extractible key and any secrets that are derived from it.  This is an
> issue if one looks at some of the composite AEAD algorithms such as the
> AES-CBC/HMAC-SHA-256 algorithm that the JOSE documents use.  If such an
> algorithm is to be used, it must be in the UA and not provided by the
> script even if all of the components of the composite algorithm are
> provided by the UA.
>
> 2.  DeriveBits cannot be used to generate both key data and non-key data
> when using a non-extractable key.   This makes it impossible, for example,
> to derive both a key and an iv from the shared secret in the same way as
> the TLS extractor done.  It would be possible to document how an extractor
> could be defined where the DeriveBits would still be permitted, but the
> data stream and the key stream would be required to be distinct by having
> the extractor mix in data that indicates the stream that the data is being
> generated for as part of the data generation process.
>
> 3.  Only those key formats that are supported by the UA can be used with a
> non-extractable key.  Thus if one wants to use a JWK key format, then that
> format must be supported by the UA or it cannot be used.
>
> 4.  If one assumes that bad code can exist, then one can only be truly
> assured that this works for named keys (i.e. those keys that are populated
> by the UA itself).  However there are some tricks that one can play with
> trying to extract and test non-extractable keys where one can potentially
> later detect that the key was not generated with the non-extractable bit
> set.
>
> Jim****
>
>  ****
>
>  ****
>
> ** **
>