Re: Registries and Interoperability

On Tue, Feb 12, 2013 at 5:21 AM, Harry Halpin <hhalpin@w3.org> wrote:
> On 02/09/2013 12:10 AM, Ryan Sleevi wrote:
>>
>> On Fri, Feb 8, 2013 at 2:52 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>>>
>>> Ok, thanks for clarifying.  I certainly agree that the flavor of interop
>>> problem you're talking about is bad.  However, that seems like a fairly
>>> straightforward issue to address, basically deduplication.  Has someone
>>> already defined AES-CBC?  If so, then you don't get an identifier for yours
>>> unless the actual algorithm differs (as opposed to the API parameter
>>> formatting).  This raises the question of whether the parameter format gets
>>> defined by the first guy that shows up, but I think you could clarify that
>>> with some guidelines.
>>>
>>> It is very common for IANA registries to have an "expert reviewer"
>>> applies before allowing registration.  (Ryan?)  It seems like you could set
>>> up a few general rules that a expert would follow to ensure some consistency
>>> in the API.  For example:
>>>
>>> -- Each algorithm gets only one identifier
>>> -- Parameters and outputs are subject to the following constraints:
>>>      -- Octet strings MUST be represented as ArrayBufferView
>>>      -- Keys (public or private) MUST be represented as Key objects, not
>>> in an encoded form
>>>      -- Integers (outside of keys) MUST be represented as integer or
>>> BigInteger values
>>>
>>> Basically, it seems like for a given algorithm, there's only a couple of
>>> more or less obvious ways to represent the algorithm and its parameters
>>> under those constraints (or something like them, to be agreed by the group).
>>> So it seems unnecessary to re-engage the WG machinery.  Especially if, as
>>> Arun suggested, the *-public mailing list can be kept alive for discussions.
>>
>> An expert reviewer is not consensus, nor is it a consensus-based
>> process, nor does it lead to actual agreement for interop.
>>
>> I feel like this is all being caught up in the machinery of 'process',
>> without any consideration with what is actually good for the web -
>> authors or implementors.
>
>
> The reason why this came up is that:
>
> 1) The cryptographic landscape can change, sometimes (although very rarely!)
> suddenly

This only applies if incorporating security considerations - which we
should not.

> 2) Identifiers for algorithms that are experimental need a place to go to
> prevent fragmentation. This avoids "prefix" problem is something that a
> registry could stop by allowing experimental algorithms to have registered
> prefix. That's good for web authors and implementers I would think.

This doesn't prevent fragmentation at all. If anything, it encourages
it, by legitimizing and attempting to 'standardize' things that are
inherently experimental in nature.

Is your concern that vendor A will experiment with some new algorithm
(say, "SHA-3") with a set of parameters defined one way, while another
vendor will experiment with the same algorithm, but defined
differently? I agree - that's concerning if exposed or treated as
'standard' - but even moreso concerning if the idea that 'slap a
registry on it' will somehow avoid that problem. No, it becomes as
useful as a 'first to file' patent system - the first to squat on a
registry name gets it.

The problem of prefixes and vendor experimentation is not new or
unique to our WG, and yet you seem to be treating it as such, with the
idea that "if we had a registry", it wouldn't be a problem. I suggest
you consult your colleagues in WebApps and HTML to see that this isn't
a magic bullet, nor is it a viable solution. It's incumbent upon user
agent implementers to make good faith effort towards standard,
interoperable implementations. Vendor prefixes were an older attempt
to do so - and an attempt that has been demonstrably shown to have
failed (see Mozilla and Microsoft adopting the "webkit-" prefix). User
agents realize that - and are working together to find alternative
solutions that still preserve the notion of a standards based web -
again, without a registry.

We're simply not going to solve this problem by having some
registration, and the continued insistence upon it is ignoring the
vast historical precedent we have to know this is the case.

>
> Your proposed solution is just not to deal with them. I think not taking
> into account 1) is an issue that may impact the usability of the API for web
> developers and its lifetime of usage in general, and 2) is simply being
> trying to keep our house in order after the lifetime of the WG.

I disagree - it acknowledges the best practices that user agents are
already working on in other groups, providing a consistent and
holistic solution to the problem, rather than trying to sit in our
corner tilting at windmills and fixing all the problems with the
standardization process. I agree, standardization is messy - but the
registry doesn't make it less messy.

Your explanation of 2 is, as I read it, the same as saying "We expect
user agents to form consensus without any manner or means to form
consensus." This is simply not reflective of the world we live in.

This may be incompatible with the W3C's goals, and may explain the
increasing relevance of the WHATWG, but the notion that the web will
somehow STOP evolving is a pretty terrible thought. Further, the idea
that somehow consensus will be formed without any manner to form
consensus is equally a terrible thought, because it leaves a magic
"???" between "Step 1) Define an algorithm" and "Step 3) Profit!". We
need to fill in that "???" - and a registry does not do that.

>
>>
>> Yes, being able to evolve the API is very useful, and something that
>> MUST be seen as inevitable (the world stands still for no one...). But
>> we must not pretend that we can both have our cake and eat it too -
>> work out consensus and deployment, and then just 'toss it over the
>> wall' for a devil-may-care approach, whether it's
>> first-come/first-serve or expert-review/benevolent-dicatatorship.
>
>
> Having a registry for experimental algorithm identifiers

What purpose does this registry solve, other than acknowledge
'experimentation is happening'. There's no need for it. No one
experimenting with new algorithms needs to a priori
acknowledge/register the experimentation - they should do the
experimentation in a way that won't break the open web. This is
readily acknowledged in other WGs, but perhaps you're not familiar
with those discussions?

> and keeping security considerations up to date

The spec should NOT be a "HOW TO" to write "secure" code. I don't know
if you've worked with much security-sensitive code, but "security" is
entirely defined by the threat model and the problems trying to be
addressed. A given algorithm may be secure under X assumptions, but
not under Y - and those assumptions are highly specific to the problem
being solved. I'm not aware of a single W3C spec that has the
requirements you're trying to impose here - that is, that it attempts
to hold authors hands on to the 'right' way to do things, and to
continually keep that up to date.

Try to put this into the context of other W3C specs. You don't see
registries of "vendor considerations" that lists down to minor
versions the exact "gotchas" associated with a given implementation.
Consider event listeners in the IE5/IE6 world - there's a huge scope
of bugs, but there's no "W3C Registry" that attempts to catalogue
"best practice".

I'm trying to offer practical advice here - the notion of maintaining
even a 'minimal' set of security considerations is enough work to keep
a room full of cryptographers busy and 'contentiously' discussing the
topic for years at end. This is why cryptography is subtle - it's not
strictly black and white, and there are a huge number of conditional
gradients. Even the simple rules and mnemonics break down under the
edge conditions - and then we're left either pretending the edge
conditions don't exist (misleading developers) or trying to describe
them all (preventing anything useful of the API getting done)

> - and keeping this all *out* of the spec
> and somewhere else, is the exact opposite of tossing the spec. It keeps the
> spec stable - the exact opposite of a "living spec" - while allowing the
> spec a path that lets it cope with unforeseen changes in the crypto
> landscape in the only two well-defined places where things are possibly
> going to change.
>
>
>>
>> Yes, implementors will certainly experiment with vendor
>> prefixes/experimental algorithms. We see this all the time. Even as I
>> think the vast majority of vendors have realized prefixes are "Bad"
>> for the Web (webkit-foo being the same as opera-foo being the same as
>> mozilla-foo helps no one, certainly not developers), at the same time,
>> the need to experiment, iterate, and deploy is all the more important
>> in working out standards that work and actually engaging the
>> community. So I certainly expect we WILL see implementors
>> experimenting with new algorithms to put forward as proposals, and
>> exposing those to the web - whether it be in Beta versions (as IE has
>> done) or through command-line flags (as Firefox has done) or through
>> 'release channels' (as Chrome has done). So if the fear is that if we
>> say 'no registry', it means none of that experimentation - well, then
>> that's flawed too - there will be experimentation REGARDLESS of what
>> we say in the spec. Just look at the activities of every other Web WG
>> to see this in action.
>
>
> It seems if we admit experimentation is likely, then having a plan for it is
> better than none. How does having no plan help?

I'm saying we use the same plan used by WebApps, used by HTML, and
used by the groups actually making progress in improving the web -
WHATWG.

>
>
>
> My concern remains first and foremost that we not pretend that any
> algorithm has 'legitimacy' or is 'ready for the web', simply by virtue
> of inclusion in some registry. That requires consensus - and it
> requires the fortitude to say, for algorithms that fail to reach
> consensus or get stuck in monoculture (eg: as WebSQL did) - that we
> must move on and NOT implement the algorithm.
>
>
> How is this not dealt with by clearly labelling a registry for experimental
> algorithm identifiers as "experimental"?

The burden of proof is to show how this is IMPROVED by a registry.
I've already set forth multiple reasons why a registry DOES NOT help.

>
> The test-suite etc. will of course be built over the algorithms in the spec.
>
>>
>>>
>>>
>>>
>>> On Feb 8, 2013, at 4:48 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>>
>>>> On Fri, Feb 8, 2013 at 1:04 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>>>>>
>>>>> Ryan,
>>>>>
>>>>> I've missed several of the intermediate messages in this thread, so
>>>>> maybe I'm missing context.  But it seems to me like you're arguing on both
>>>>> sides here.
>>>>>
>>>>> (A) On the one hand, you argued strenuously at the Mountain View F2F
>>>>> that the API spec should not specify which algorithms a UA is required to
>>>>> implement.  Among other reasons, a UA that uses an OS-provided crypto
>>>>> library might not have control over which algorithms.
>>>>>
>>>>> (B) On the other hand, you are now saying that we need a consistent set
>>>>> of algorithms for there to be a coherent web API.  Just like we have a
>>>>> consistent set of HTML tags, and discourage UA vendors from adding custom
>>>>> tags.
>>>>>
>>>>> These two positions are fundamentally in conflict.  If there is going
>>>>> to be a consistent set of algorithms, then the API will have to have
>>>>> requirements for UAs.  If there are no requirements for UAs, there is no
>>>>> guarantee of consistency.  Which side are you on?
>>>>
>>>> You misrepresent my position and the arguments.
>>>>
>>>> As mentioned during Mountain View, MTI is troublesome from an API
>>>> perspective, which is what you put as (A). This was specifically in
>>>> the context of supporting arbitrary Keys (for which not algorithms are
>>>> possible, due to the underlying storage requirements, whatever they
>>>> may be), and in acknowledgement of the complex regulatory frameworks
>>>> surrounding crypto and strong crypto (c.f., France, as an example).
>>>> That said, in a pure-software-only mode (eg: now that the Netflix
>>>> requirements are separate), it MAY be worth revisiting - but even if
>>>> we end up with MTIs now, we'll be back in the situation of non-MTIs
>>>> within X years, as we support different versions of the spec.
>>>>
>>>> However, I'm also a strong believer in interop, which you put as (B).
>>>> What this specifically means is a strong objection to seeing
>>>> vendor1-AES-CBC, vendor2-AES-CBC, and vendor3-AES-CBC, all of which
>>>> are incompatible in their own wonderfully and stupendously stupid
>>>> ways. This is not an idle concern - we see it time and time again with
>>>> web registries.
>>>>
>>>> I'm not talking about purely naming concerns - I'm talking about the
>>>> functionality exposed, parameters, the handling of inputs and the
>>>> resulting outputs. Consider, for example, your ECDH concerns. Vendor 1
>>>> may "register" an algorithm in the registry that uses a Key object,
>>>> while Vendor 2 may register an algorithm that uses an ArrayBufferView.
>>>>
>>>> A web developer MUST NOT be required to test some n-number of
>>>> potential interpretations of what "ECDH" means, in addition to any
>>>> necessary polyfill. There should be a single, consensus-driven
>>>> agreement on the necessary parameters, inputs, and outputs that define
>>>> it. A registry does not define that process.
>>>>
>>>> So then, if the registry doesn't define the process, doesn't define
>>>> the requirements - eg, the registry behaves like many IANA registries
>>>> that require "WG approval" (c.f. "IETF consensus"), then we're back to
>>>> the situation that Harry claims we'll somehow be able to avoid -
>>>> needing the WG to be open and review.
>>>>
>>>> (A) and (B) are not in conflict.
>>>>
>>>>
>>>>> This question is fundamental to the identifier/registry question.  (A)
>>>>> If there are no requirements, then web developers will have to check that
>>>>> algorithms are present anyway (cf. caniuse.com), so an IANA registry with
>>>>> fairly liberal requirements makes sense.  (B) If there are requirements,
>>>>> then UA developers will have to coordinate which algorithms are required, so
>>>>> it makes sense to go through the W3C process to update the list.
>>>>>
>>>>> --Richard
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Feb 8, 2013, at 3:48 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>>>>
>>>>>> On Fri, Feb 8, 2013 at 12:00 PM, Harry Halpin <hhalpin@w3.org> wrote:
>>>>>>>
>>>>>>> On 02/08/2013 08:45 PM, Ryan Sleevi wrote:
>>>>>>>>
>>>>>>>> On Fri, Feb 8, 2013 at 11:30 AM, Harry Halpin <hhalpin@w3.org>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On 02/07/2013 10:48 PM, Arun Ranganathan wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Feb 7, 2013, at 12:27 PM, Harry Halpin wrote:
>>>>>>>>>
>>>>>>>>> No, the process I suggested generally would involve handing off
>>>>>>>>> after the
>>>>>>>>> lifetime of a WG the following two items:
>>>>>>>>>
>>>>>>>>> 1) maintaining security considerations per identifier to the CFRG,
>>>>>>>>> which
>>>>>>>>> operate on a public list
>>>>>>>>> 2) maintaining requests for a new algorithm identifiers in a public
>>>>>>>>> registry, with requests on a public list and the test-cases being
>>>>>>>>> publican
>>>>>>>>> accessible.
>>>>>>>>>
>>>>>>>>> Some may consider this sensible as the crypto landscape does change
>>>>>>>>> and
>>>>>>>>> will
>>>>>>>>> thus likely change after the lifespan of this WG.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It is true that much of the process behind WebApps and HTML is
>>>>>>>>> bolstered
>>>>>>>>> by
>>>>>>>>> the fact that we don't envision these WGs as ever really "closing"
>>>>>>>>> (which
>>>>>>>>> might be like saying the web's done).  I'm wondering if W3C might
>>>>>>>>> be
>>>>>>>>> amenable to another model that doesn't involve re-chartering a WG,
>>>>>>>>> but
>>>>>>>>> does
>>>>>>>>> allow for spec and/or document maintenance, which is what draws me
>>>>>>>>> to the
>>>>>>>>> WHATWG, which is another option, if there's a willing editor.
>>>>>>>>>
>>>>>>>>> For instance, new identifiers (2. above) reminds me of the
>>>>>>>>> potentially
>>>>>>>>> ongoing problem of DOMException and DOMError.  Both WHATWG DOM Spec
>>>>>>>>> [1]
>>>>>>>>> and
>>>>>>>>> the DOM4 [2] specification in W3C cite the W3C Bug Database as a
>>>>>>>>> way of
>>>>>>>>> adding new exception codes, if necessary (the latest added one
>>>>>>>>> comes from
>>>>>>>>> File API, namely EncodingError).   I'm not sure we can totally
>>>>>>>>> classify
>>>>>>>>> DOMException and DOMError as "done" for all time.  I think it's
>>>>>>>>> likely to
>>>>>>>>> be
>>>>>>>>> the same with Web Crypto, since saying anything security related is
>>>>>>>>> "done"
>>>>>>>>> is unwise, as is the assumption that further algorithms won't
>>>>>>>>> proliferate.
>>>>>>>>>
>>>>>>>>> Instead of a registry, can we do something like active bug
>>>>>>>>> discussions,
>>>>>>>>> and
>>>>>>>>> keep *public active?  This is what makes WHATWG attractive, but I
>>>>>>>>> understand
>>>>>>>>> that patent considerations might limit the merits of merely
>>>>>>>>> migrating
>>>>>>>>> there.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When a WG closes, public-webcrypto@w3.rg closes as the WG is
>>>>>>>>> closed. The
>>>>>>>>> comments list can stay open.
>>>>>>>>>
>>>>>>>>> My feeling here is that of course we can keep the Bug Database
>>>>>>>>> open, and
>>>>>>>>> I
>>>>>>>>> hope we do so, as well as the test-suite.
>>>>>>>>>
>>>>>>>>> However, that's not the cases that have been brought up. The two
>>>>>>>>> cases
>>>>>>>>> are:
>>>>>>>>>
>>>>>>>>> 1) A web developer wants to see if a new experimental algorithm
>>>>>>>>> identifier
>>>>>>>>> can be added. That could be done in the Bugzilla, but that might be
>>>>>>>>> hard
>>>>>>>>> to
>>>>>>>>> discover/reference amongst other bugs - and then text needs to be
>>>>>>>>> clear
>>>>>>>>> about that as a use of the Bugzilla. A registry might be easier.
>>>>>>>>> But
>>>>>>>>> maybe
>>>>>>>>> not.
>>>>>>>>>
>>>>>>>>> 2) A web developer needs to know the security considerations for an
>>>>>>>>> algorithm identifier. I think CFRG should handle that rather than
>>>>>>>>> our
>>>>>>>>> API,
>>>>>>>>> and we should explicitly point to them in our API documents as well
>>>>>>>>> as
>>>>>>>>> the
>>>>>>>>> "larger cryptographic literature".
>>>>>>>>
>>>>>>>> As I pointed out on our last call and on the list in the past, I do
>>>>>>>> not believe our API documents should have any considerations on the
>>>>>>>> algorithms. This solves your problem, does it not?
>>>>>>>
>>>>>>>
>>>>>>> No that doesn't as that does not resolve CFRG's comment, which will
>>>>>>> come up
>>>>>>> at Last Call. I *agree* our API documents will not have
>>>>>>> considerations on
>>>>>>> the algorithms. I do think its reasonable that we point people to a
>>>>>>> document
>>>>>>> not maintained by us that does maintain security considerations. Do
>>>>>>> you
>>>>>>> think we should not point to anything about the security
>>>>>>> considerations of
>>>>>>> algorithms at all?
>>>>>>
>>>>>> Harry,
>>>>>>
>>>>>> Professor Paterson is the member from the CFRG who made the comment.
>>>>>>
>>>>>> It seems like you're pushing this point based on your understanding of
>>>>>> the feedback, but what's really clear is that we're in disagreement
>>>>>> about the feedback received. If you look at the feedback received,
>>>>>> you'll see the integrated changes ARE consistent with the
>>>>>> recommendation.
>>>>>>
>>>>>> And you're now talking about something entirely different from a
>>>>>> registry for algorithms, which I think muddies the waters even more.
>>>>>> At best, it becomes a 'registry for security considerations', which is
>>>>>> something that is well and truly wholly independent and unrelated to
>>>>>> this work.
>>>>>>
>>>>>>>
>>>>>>>> In discussing with a variety of people in the cryptographic
>>>>>>>> community,
>>>>>>>> the discussion has been less about enumerating every algorithm's
>>>>>>>> considerations and more about highlighting the fact that these are
>>>>>>>> low-level primitives that MAY be deployed incorrectly, and thus care
>>>>>>>> and caution must be exercised.
>>>>>>>>
>>>>>>>> In discussing with people like Professors Kenny Paterson and Dan
>>>>>>>> Boneh, along with people from Microsoft and Mozilla, the consensus
>>>>>>>> seems to be that if we're going to include low-level primitives
>>>>>>>> (which
>>>>>>>> has been the ongoing momentum since FPWD), it is sufficient to mark
>>>>>>>> them as 'subtle', with language to indicate that unless you're part
>>>>>>>> of
>>>>>>>> the crypto-priesthood, or implementing something that the
>>>>>>>> crypto-priesthood has deigned acceptable (eg: any of the protocols
>>>>>>>> out
>>>>>>>> there that are desirable to implement), then that's a "sufficient"
>>>>>>>> consideration.
>>>>>>>
>>>>>>>
>>>>>>> That was not the response from Ron Rivest or the CFRG. Note that MIT
>>>>>>> is a
>>>>>>> member of the W3C, and if IESG has concerns, we have to address them.
>>>>>>> Addressing them in a way that causes no or minimal changes to the
>>>>>>> text in
>>>>>>> the API is I think the best way.
>>>>>>
>>>>>> And that's why we should not include algorithm-specific considerations
>>>>>> in the text, because the literature will always evolve and the
>>>>>> algorithms will always get weaker over time. That's true for any
>>>>>> developer who were to use this API to write code today, the same as it
>>>>>> would be for any developer who reviewed the API 10 years from now.
>>>>>>
>>>>>> I don't see any of your concern of 'living spec because of security
>>>>>> considerations' precisely because we should not be including security
>>>>>> considerations that need to be 'living spec'.
>>>>>>
>>>>>>>> This has already been incorporated in the latest ED - see
>>>>>>>> https://dvcs.w3.org/hg/webcrypto-api/rev/17347680f504 . While I
>>>>>>>> certainly don't know whether that will satisfy Dr. Rivest, everyone
>>>>>>>> I
>>>>>>>> talked to about the subtle proposal was satisfied from a
>>>>>>>> considerations point of view.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Again, having W3C liason with CFRG, IANA, and so on takes time,
>>>>>>>>> which is
>>>>>>>>> why
>>>>>>>>> this is being brought up now :) W
>>>>>>>>>
>>>>>>>>>    cheers,
>>>>>>>>>     harry
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- A*
>>>>>>>>>
>>>>>>>>> [1] "Note: If an error name is not listed here, please file a bug
>>>>>>>>> as
>>>>>>>>> indicated at the top of this specification and it will be addressed
>>>>>>>>> shortly.
>>>>>>>>> Thanks!" http://dom.spec.whatwg.org/#error-names-0
>>>>>>>>>
>>>>>>>>> [2] "If an error name is not listed here, please file a bug as
>>>>>>>>> indicated
>>>>>>>>> at
>>>>>>>>> the top of this specification and it will be addressed shortly.
>>>>>>>>> Thanks!"
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#exception-domexception
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>

Received on Thursday, 14 February 2013 00:57:51 UTC