Re: Using WebCrypto to implement security protocol

On Wed, Oct 9, 2013 at 11:48 AM, Joshua Cranmer 🐧 <Pidgeot18@gmail.com>wrote:

> On 10/9/2013 12:34 PM, Ryan Sleevi wrote:
>
>> On Wed, Oct 9, 2013 at 9:59 AM, Joshua Cranmer <pidgeot18@gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> I have been looking into the feasibility of using the WebCrypto API as
>>> specified in the current draft in order to implement a pre-existing
>>> security
>>> protocol, that of the Off-the-Record protocol supported in some chat
>>> clients. A link to the full specification of this protocol may be found
>>> here: <https://otr.cypherpunks.ca/**Protocol-v3-4.0.0.html<https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html>>;
>>> I am not involved
>>> in creating or modifying this specification in any way, and I merely
>>> wish to
>>> implement this using WebCrypto.
>>>
>>> The biggest issue in WebCrypto that I have found is that it lacks the
>>> ability to support DSA, which the OTR specification uses as the sole
>>> supported algorithm for the final two steps of the authenticated key
>>> exchange. In searching the archives of the mailing lists, it seems that
>>> this
>>> omission is intentional and not accidental, but I have found no explicit
>>> indication of why this is the case. Since implementations are free to add
>>> extra algorithms, I was also wondering if anyone was planning on adding
>>> support For DSA in their implementations.
>>>
>> Given the size limitations of DSA (mod DSA2), is there a reason not to
>> migrate towards ECDSA - which is supported?
>>
> The specification I'm working with is one that I have no control over.
> Since there is already a large body of software using this specification
> that supports DSA keys, I'd need to be able to support them as well. From
> reading mailing list archives, there is an idea to support ECDSA, but
> implementation is held off to being "problematic patent-wise" (I stand no
> opinion on this issue).
>
>
>  The reasons for omitting DSA (or more aptly, questioning
>> implementation), which themselves are quite weak and subject to
>> change:
>> 1) Smaller security parameters (unless you've implemented DSA2)
>> 2) No one asked for it
>>
> Consider me as someone asking for it. :-) As the specification currently
> doesn't seem to be leaning towards a mandatory set of algorithms for
> implementation, it might be advisable to at least specify what the
> interface for key parameters should look like for those who do desire to
> implement it.
>
>
>  Another complication I found was in trying to use the AES and HMAC
>>> algorithm. The specification derives the keys as byte arrays from the
>>> results of other algorithms, but it is not immediately clear to me how to
>>> use these byte arrays as keys. I have been provisionally filling these in
>>> as:
>>>      crypto.importKey({name: "HMAC", hash: "SHA-256"}, m1)
>>> but the general lack of specification here makes it hard to tell if this
>>> is
>>> a correct mode or not.
>>>
>> I'm not sure I follow the question. Is the issue the lack of
>> specification for key formats?
>>
>> For importing a sequence of bytes as an HMAC key
>>
>> var promise = window.crypto.subtle.**importKey("raw", m1, { name:
>> "HMAC", hash: "SHA-256"}, ...);
>>
>
> I think that looks like it should do what I desire. I might advise
> including an example in the document. :-)
>
>
>  A final point of interest is that I would like, in general, to have
>>> support
>>> for a browser-secured keystore (which would presumably integrate more or
>>> less with a system keystore), but it's not clear to me if that is in
>>> scope
>>> for this working group.
>>>
>> I'm not sure I fully understand this request. Key storage is something
>> we've (intentionally) omitted, but I'm trying to understand what the
>> actual properties are that you would desire/expect from such a store,
>> to see if this is something already addressed by the spec.
>>
>>  It is almost certainly possible to develop a keystore over local storage
> and the cryptographic primitives, but what that lacks is integration with
> the browser's keystore (such as where it stores passwords). It seems like
> it would be a good idea to me to have an API that could let websites store
> private keys in the same or a similar key storage so that it could be
> easily integrated with features such as, e.g., a master password.


Nothing needs to be specified in the spec - that's an implementation.

That is, all that is required is that Key objects be structured clonable. A
browser implementation could protect such keys when persisted to IDB by
encrypting them with some password derived from a master password.

Individually speaking, such things are complete security theater, and I
would prefer not to see the spec even pretend they add value. However, as
far as the spec goes, it says nothing one way or the other, which is
intentional - unless UAs are required to implement said security theater,
then there's no added security (since some UAs will, correctly, not
implement that).

Let me put it differently: Is there anything in the spec that, in your
view, would *prevent* an implementation for implementing what you propose?
If not, given that not all UAs support or want to support a notion like
"master password", and may have alternative, more secure methods, it seems
best to leave this free for implementations to differentiate themselves on.