Re: SubtleCrypto

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.

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

> 
>> 
>> 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.

> 
>> 
>> 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:21:28 UTC