Re: SubtleCrypto

On Thu, Nov 7, 2013 at 2:20 PM, Oliver Hunt <oliver@apple.com> wrote:
>
> On Nov 7, 2013, at 1:56 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>> On Thu, Nov 7, 2013 at 1:32 PM, Oliver Hunt <oliver@apple.com> wrote:
>>> Hi all, I’ve been following the spec and various discussions regarding subtle crypto (and the WebCrypto spec in general) and i do have a few concerns.
>>>
>>> My opinion is that WebCrypto should make the simplest and most obvious thing to do be correct.  That is the API should be a small as possible, and have only those primitives that are absolutely necessary for encryption, decryption, authenticity, and message verification.  It should not require extra work, or separate steps for any of these — I would argue that any encryption perform should default to providing an content blob that is encrypted and includes at minimum verification, and should make it _hard_ to override that default.
>>
>> Greetings Oliver,
>>
>> I'm glad you're getting up to speed on this. This particular point has
>> been a point that's been discussed since the very beginning of the WG,
>> so there's certainly a lot of discussion here.
>>
>> In order to avoid rehashing much of the conversation, I'd like to pose
>> two hopefully simple questions:
>>
>> 1) What use cases do you see this supporting?
>>  Context: The choice of use cases directly influences the choice of
>> crypto combinations. Do you choose pre-built compositions like NaCl or
>> KeyCzar, do you allow caller-specified combinations like JOSE, do you
>> handle agreement schemes like OTR/mpOTR, do you handle deniability
>> like Pond, or do you invent something new entirely?
>
> I need to think about this more.  In the absence of an existing crypto standard or protocol that provides authenticity + verification as part of the standard transmission stream, i would prefer a new protocol to simply continuing the series of crypto apis that make it hard to do the right thing, and trivial to do it wrong.
>
>>
>> 2) How will you address the other use cases that have been identified
>> with great enthusiasm by a number of members in this WG, ranging from
>> certificate-based authentication schemes to supporting Javascript
>> Applications (whether via Extensions/SysApps/Win8-Metro apps or simple
>> hosted-in-a-page apps) with such a scheme?
>
> I would say step one of a new crypto api is to define a mechanism that handles the most basic use cases without making incorrect behaviour possible.

I guess I was asking what you see as "the most basic use cases".

When you enumerate the use cases (and their corresponding threat
models), it becomes quickly apparent that in order to actually satisfy
the diversity of use cases, you really do need composable low-level
primitives.

My fear with defining some mechanism like you describe is that we end
up in a world of VRML, when really what developers want (and need) is
WebGL. Even though the edges are unquestionably sharper (ha ha), it
provides a much more robust and usable API.

That said, in the past discussions, there have been a number of calls
for proposals of such a high level API, along with use cases for it,
but so far, no one has stepped forward to offer such an API or justify
its necessity.

>
> Supporting arbitrary crypto for non-standard schemes is secondary and can - if absolutely necessary - go under the unsafe namespace

The conclusion reached during past discussions and face-to-face was
the opposite. That is, supporting arbitrary crypto is a primary
concern, as it allows a robust level of polyfills, and supporting
'opionated' crypto-designs (whether the adoption of elements of
JOSE/JWS/JWK/JWT or of some new protocol) are secondary.

There is certainly tension with an API that's impossible to get wrong,
but not of much use, and an API that is difficult to get right, but
rich enough to support a plethora of applications, and the WG has
repeatedly affirmed a commitment to the latter.

>
>>
>>>
>>> I’m also weary of providing byte array representation of any of the core primitives as history has shown that doing so leads to developers creating timing attacks.
>>
>> I would hope you could elaborate on this, since the very design is to
>> reduce such timing attacks, by providing a sufficiently high level
>> abstraction that timing sensitive operations (such as checking the
>> padding bytes of a PKCS#1 message) are done within the implementation.
>
> Historically people have iterated byte streams to verify equality.  Providing an API to do this correctly is fairly meaningless when there is an obvious mechanism (for(...) ) that allows developers to do the wrong thing means that they will.

Certainly, constant-time and correct comparisons are one of the key
motivations for this API, as it cannot be (reliably) implemented
purely in JS. That is, while it may be possible to implement for a
specific UA based on internal knowledge of its JS implementation and
optimizer, a generic solution is not readily available.

That said, such comparisons are designed to be unnecessary by the API.
This is why, for example, HMAC supports "Verify", even though one does
not traditionally think of such from an API. This allows the
implementation to "do the right thing", such as to do the
constant-time memory equality check.

I'm not sure what you see as the alternative to this, although perhaps
it's also conditioned on the presumption that the WG will define a
cryptographic protocol (which we said was out of scope) and expose
that via an API. If we were to use other data representation types
(eg: DOMString), we'd be back in the same boat, since people would no
doubt be doing string equality comparisons.

I'm extremely sensitive to the risk of timing issues, having had to
work through them with a number of underlying cryptographic libraries,
and that's why I've tried to promote a design that hides as much as
these details as possible. If you have specific concerns, I would love
to know, so that we can see how to address via the API, but I fear
perhaps this is the general desire to see a 'high-level' API.

>
>>
>>>
>>> I am strongly opposed to the current SubtleCrypto _name_.  I recognise the need for these low level primitives for interacting with arbitrary encrypted mediums, but the naming is weak.
>>>
>>> “Subtle" does not convey the risk involved as it is vaguely ambiguous to native english speakers, and much worse for non-native english speakers.  I think the spec should replace “subtle” with the much stronger and less ambiguous term “unsafe”, this makes it very clear that using the API is risky, and would hopefully discourage developers from using it directly.
>>
>> Is it correct to say you would disagree with the position that
>> "unsafe" is a misnomer, given that nothing about these operations is
>> *inherently* unsafe, but MAY be use unsafely?
>>
>> Consider, for example, AES-CBC or AES-CTR. It's possible to use them
>> incorrectly (eg: without a MAC, without a fresh IV), but it's equally
>> possible to build semantically secure and strong encryption schemes
>> with desirable benefits (compared to, say, AES-GCM).
>
> "Subtle" completely fails to say what the problem with the APIs is.  What does “subtle” mean?  Here’s a few possible interpretation of subtle:
> * It’s weak
> * It’s encryption designed to hide that it’s encrypted content
>
> “Unsafe” is a more forceful way to say that the API should be avoided.  Unsafe is frequently used in existing literature to indicate features that may lead to unsafe behaviour, even though they can be used safely (Say ecma 334)
>
> —Oliver
>
>>
>>>
>>> I’m still getting up to speed with the API, and I just found the spec version i was reading was actually an old draft so i’m going to hold back on more specific critiques until i’ve read the newest drafts.
>>>
>>> —Oliver
>>>
>>
>

Received on Thursday, 7 November 2013 22:34:48 UTC