Subject: [saag] Paper for W3C Identity in the Browser Workshop

From: Sean Turner <[email-masked]>
Date: Tue, 26 Apr 2011 09:00:23 -0400

Please find below a paper Stephen and I are hoping to submit to the W3C 
Identity in the Browser Workshop (24-25 May in Mountain View, 
California).  We'd like to submit it as the IETF Security Area 
Directors, but we'd obviously like to get comments from the saag list. 
The deadline for submissions is April 27th.  I apologize for the very 
short deadline.

spt

=====================================================================

Abstract

This position paper aims to provide some motivations for an Application 
Programming Interface (API) that will allow developers access to 
cryptographic algorithms already present in today's web browsers.

Motivations

More and more applications are moving to the "web" (i.e., 
http://www.example.com:80 and http://www.example.com:443).  Developers 
are working within the confines of browsers to secure these applications 
and most use Secure Sockets Layer (SSL)/Transport Security Layer (TLS) 
to do so.  For applications whose architectures are not strictly 
client-server this reliance is not always optimal.  As a work around, 
developers are investigating the use of JavaScript Object Notation 
(JSON) for application layer security protocols and cryptographic 
algorithms.  Use of JSON makes some sense in an application layer 
security protocol but developers rolling and then delivering their own 
cryptographic algorithms is not only wasteful but is possibly insecure 
when the browser's security "goodies" (i.e., the cryptographic 
algorithms) are just an Application Programming Interface (API) away.

Downloading cryptographic algorithms is wasteful in terms of bandwidth 
used.  Application and browser developers are both very interested in 
ensuring their applications are speedy in the eyes of users; nobody 
wants to loose a speed war on cnet®.  If web developers end up rolling 
their own cryptographic algorithms to support a JSON application layer 
security protocol, then the code may end up being downloaded during 
application initialization.  Cryptographic code could include: message 
digest/hash algorithms, digital signature algorithms, content encryption 
algorithms, key wrap algorithms, keyed-Hash Message Authentication Code 
(HMAC) algorithms, etc.

Developers rolling their own cryptographic code could be insecure.  As 
Steve Bellovin pointed out in RFC 5406: The design of security protocols 
is a subtle and difficult art.  In fact, it is worse: coding security 
protocols is even more subtle and difficult than designing the security 
protocol.  There is no doubt that some developers will get it right the 
first time but there is also no doubt that some will get it wrong.  With 
cryptographic algorithms already coded in browsers and some having been 
National Institute of Standards and Technology (NIST) Federal 
Information Processing Publication (FIPS PUB) 140 evaluated, it seems 
unnecessarily risky to not utilize the cryptographic algorithms already 
present in the browser.

Greedy Goals

An API that allows web developers to access browser-embedded 
cryptographic algorithms would include the following:

o Support for hash/message digest algorithms (e.g., SHA-256);
o Support for digital signatures algorithms (e.g., RSA PKCS#1 v1.5, ECDSA);
o Support for confidentiality algorithms (i.e., AES);
o Support for key transport/agreement algorithms (e.g., RSA PKCS#1 v1.5, 
ECDH);
o Support for HMAC algorithms (e.g., HMAC-SHA1, HMAC-SHA256);
o Support extracting keys from TLS sessions ala RFC 5176;
o Support for PKI path validation (i.e., input/output of base64 
certificate/crl/ocsp blobs), and;
o Support for Cryptographic Message Syntax (CMS).

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Apr 2011 09:51:40 -0400

Overall, this paper looks great to me.  I would love to see such an API deployed and widely used.  

Couple of minor comments inline below.

On Apr 26, 2011, at 9:00 AM, Sean Turner wrote:

> Please find below a paper Stephen and I are hoping to submit to the W3C Identity in the Browser Workshop (24-25 May in Mountain View, California).  We'd like to submit it as the IETF Security Area Directors, but we'd obviously like to get comments from the saag list. The deadline for submissions is April 27th.  I apologize for the very short deadline.
> 
> spt
> 
> This position paper aims to provide some motivations for an Application Programming Interface (API) that will allow developers access to cryptographic algorithms already present in today's web browsers.
> 
> Motivations
> 
> More and more applications are moving to the "web" (i.e., http://www.example.com:80 and http://www.example.com:443).  Developers are working within the confines of browsers to secure these applications and most use Secure Sockets Layer (SSL)/Transport Security Layer (TLS) to do so.  For applications whose architectures are not strictly client-server this reliance is not always optimal.  As a work around, developers are investigating the use of JavaScript Object Notation (JSON) for application layer security protocols and cryptographic algorithms.  Use of JSON makes some sense in an application layer security protocol but developers rolling and then delivering their own cryptographic algorithms is not only wasteful but is possibly insecure when the browser's security "goodies" (i.e., the cryptographic algorithms) are just an Application Programming Interface (API) away.

Technically, JSON is not being used for the cryptographic algorithms, since it's just an encoding.  The concern is new ad-hoc Javascript crypto libraries.  Suggested text:
"
Developers are investigating the creation of new Javascript-based cryptography libraries and new formats for signed and encrypted objects based on JavaScript Object Notation (JSON).
"

> Downloading cryptographic algorithms is wasteful in terms of bandwidth used.  Application and browser developers are both very interested in ensuring their applications are speedy in the eyes of users; nobody wants to loose a speed war on cnet®.  If web developers end up rolling their own cryptographic algorithms to support a JSON application layer security protocol, then the code may end up being downloaded during application initialization.  Cryptographic code could include: message digest/hash algorithms, digital signature algorithms, content encryption algorithms, key wrap algorithms, keyed-Hash Message Authentication Code (HMAC) algorithms, etc.

Probably also worth pointing out the obvious security risk that if someone forgets to use HTTPS for the crypto library download, then an attacker can feed them a bad library.

> Developers rolling their own cryptographic code could be insecure.  As Steve Bellovin pointed out in RFC 5406: The design of security protocols is a subtle and difficult art.  In fact, it is worse: coding security protocols is even more subtle and difficult than designing the security protocol.  There is no doubt that some developers will get it right the first time but there is also no doubt that some will get it wrong.  With cryptographic algorithms already coded in browsers and some having been National Institute of Standards and Technology (NIST) Federal Information Processing Publication (FIPS PUB) 140 evaluated, it seems unnecessarily risky to not utilize the cryptographic algorithms already present in the browser.
> 
> Greedy Goals

How about just "Goals"?

> An API that allows web developers to access browser-embedded cryptographic algorithms would include the following:
> 

s/i.e./e.g./

> o Support for key transport/agreement algorithms (e.g., RSA PKCS#1 v1.5, ECDH);

s/ala RFC 5176/(e.g., using RFC 5176)/

> o Support for PKI path validation (i.e., input/output of base64 certificate/crl/ocsp blobs), and;
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Carl Wallace <[email-masked]>
Date: Tue, 26 Apr 2011 10:53:51 -0400

>certificate/crl/ocsp blobs), and;

Add support for providing path validation algorithm inputs and receiving
path validation algorithm outputs.  It probably wouldn't hurt to try to
break reliance on unconstrained trust anchors in a new API too.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 Apr 2011 17:05:19 +0200

Sean,

On 4/26/11 3:00 PM, Sean Turner wrote:
> are working within the confines of browsers to secure these
> applications and most use Secure Sockets Layer (SSL)/Transport
> Security Layer (TLS) to do so.  For applications whose architectures
> are not strictly client-server this reliance is not always optimal. 
> As a work around, developers are investigating the use of JavaScript
> Object Notation (JSON) for application layer security protocols and
> cryptographic algorithms.  Use of JSON makes some sense in an
> application layer security protocol but developers rolling and then
> delivering their own cryptographic algorithms is not only wasteful but
> is possibly insecure when the browser's security "goodies" (i.e., the
> cryptographic algorithms) are just an Application Programming
> Interface (API) away.

I would in this case suggest stronger language.  "possibly insecure" is
too wishy washy.  I would consider using the term "dangerous".  For
supporting information, consider every last update it took to get
openssl as correct as it is today.  Now imagine some script kiddy doing
that sort of stuff.

---

From: Sean Turner <[email-masked]>
Date: Tue, 26 Apr 2011 11:16:41 -0400

Richard,

Thanks for the review.  Responses inline.

spt

> Developers are investigating the creation of new Javascript-based cryptography libraries and new formats for signed and encrypted objects based on JavaScript Object Notation (JSON).

Yeah that makes sense.  Done.

> Probably also worth pointing out the obvious security risk that if someone forgets to use HTTPS for the crypto library download, then an attacker can feed them a bad library.

Err yeah.  I'll add:

Obviously, downloading cryptographic algorithms is also an easy attack 
vector if not done over https.

>> Developers rolling their own cryptographic code could be insecure.  As Steve Bellovin pointed out in RFC 5406: The design of security protocols is a subtle and difficult art.  In fact, it is worse…

I was trying to be cheeky.  We are asking them to do all the work after 
all.  But, I see you're point.

>> o Support for confidentiality algorithms (i.e., AES);

I actually did this on purpose because I hope to avoid the "please 
include my vanity crypto too" discussion.  But, they can probably figure 
that out.
> s/ala RFC 5176/(e.g., using RFC 5176)/

done.

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 26 Apr 2011 21:13:00 +0300

Hi Sean,

last I checked, JavaScript did not provide any sort of reasonable 
crypto-quality random number generator, nor even a lower quality PRNG, 
for that matter.

The JavaScript community is used to downloading major libraries along 
with the Web page (e.g. JQuery). This is arguably inelegant, but it 
works. It could also work fine for the crypto algorithms you list. The 
only case where you MUST use the local resources is random number 
generation.

In other words: please add RNG to your list of goals.

Thanks,
	Yaron

On 04/26/2011 04:00 PM, Sean Turner wrote:
> California). We'd like to submit it as the IETF Security Area Directors,
> but we'd obviously like to get comments from the saag list. The deadline
> for submissions is April 27th. I apologize for the very short deadline.
>
> spt
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 26 Apr 2011 13:43:55 -0600

> In other words: please add RNG to your list of goals.

How about:

o Methods for using local resources to generate random (or
pseudo-random) numbers

Here is a revised version of the position paper. (I've added myself as a
submitter because Sean and Stephen can't participate in the workshop due
to other obligations, so I offered to present the topic if the proposal
is accepted.)

###

Submitters

Sean Turner
Stephen Farrell
Peter Saint-Andre

Abstract

This position paper advocates an Application Programming Interface (API)
that will enable developers access to cryptographic algorithms already
present in today's web browsers.

Motivations

More and more applications are moving to the "web" (e.g.,
http://app.example.com:80 and https://app.example.com:443).  Developers
are working within the confines of various browsers to secure these
applications, and most use Secure Sockets Layer (SSL)/Transport Security
Layer (TLS) to do so.  This reliance is sub-optimal for applications
whose architectures are not strictly client-server (e.g., IM and VoIP).
 As a workaround, developers are currently investigating the creation of
new Javascript-based cryptography libraries, along with new formats for
signed and encrypted objects based on JavaScript Object Notation (JSON).
 Use of JSON makes some sense in an application layer security protocol.
 However, it makes less sense for developers to roll (and deliver) their
own cryptographic algorithms -- it's not only wasteful, it's also
dangerous when the browser's security "goodies" (i.e., the cryptographic
algorithms) are just an API away.

Downloading cryptographic algorithms is wasteful in terms of bandwidth
used.  Application and browser developers are both very interested in
ensuring their applications are speedy in the eyes of users; nobody
wants to lose a speed war on CNET.  If web developers end up rolling
their own cryptographic algorithms to support a JSON application layer
security protocol, then the code may end up being downloaded during
application initialization.  Such cryptographic code could include
message digest/hash algorithms, digital signature algorithms, content
encryption algorithms, key wrap algorithms, and keyed-Hash Message
Authentication Code (HMAC) algorithms.  This kind of code is typically
not small because of the significant math involved in producing strong
security.

However, the greatest danger here is not a waste of bandwidth, but
possible security breaches.  Obviously, downloading cryptographic
algorithms is an easy attack vector if not done over SSL/TLS.  But the
real challenge is that security is hard.  As Steve Bellovin pointed out
in RFC 5406, the design of security protocols is a subtle and difficult
art.  In fact, coding security protocols is even more subtle and
difficult than designing security protocols.  There is no doubt that
some developers will get it right the first time, but there is also no
doubt that some will get it wrong.  Given that cryptographic algorithms
alread coded into browsers (and that some of them have already been
evaluated by the U.S. National Institute of Standards and Technology
(NIST) for compliance with Federal Information Processing Publication
(FIPS PUB) 140), it seems unnecessarily risky to not make use of the
cryptographic algorithms already present in the browser.  A consistent
API for access to those algorithms would provide a strong foundation for
securing the web.

Goals

We propose that a consistent web security API would support the
following algorithms and functions:

o Hash/message digest algorithms (e.g., SHA-256)
o Digital signatures algorithms (e.g., RSA PKCS#1 v1.5, ECDSA)
o Confidentiality algorithms (e.g., AES)
o Key transport/agreement algorithms (e.g., RSA PKCS#1 v1.5, ECDH)
o HMAC algorithms (e.g., HMAC-SHA1, HMAC-SHA256)
o Methods for extracting keys from TLS sessions (e.g., using RFC 5176)
o Methods for PKI path validation (e.g., input/output of base64
certificate/CRL blobs)
o Methods for generating and processing Cryptographic Message Syntax (CMS)
o Methods for using local resources to generate random (or
pseudo-random) numbers

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 26 Apr 2011 23:34:54 +0300

Sounds good. Although it's obvious to us, I would add "of cryptographic 
strength".

Thanks,
	Yaron

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 26 Apr 2011 14:39:46 -0600

Changed in my working copy to:

o Methods for using local resources to generate random (or
pseudo-random) numbers of cryptographic strength

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 Apr 2011 22:49:29 +0200

> o Support extracting keys from TLS sessions ala RFC 5176;

Shouldn't this be RFC 5705?

> o Support for Cryptographic Message Syntax (CMS).

My wishlist would include:

o Support for getting TLS channel binding ala RFC 5056/5929

/Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 26 Apr 2011 14:56:04 -0600

> Shouldn't this be RFC 5705?

Indeed.

> o Support for getting TLS channel binding ala RFC 5056/5929

Yes, that is desirable as well (probably the reference to RFC 5929 is
sufficient).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Apr 2011 22:27:02 +0100

> Yes, that is desirable as well (probably the reference to RFC 5929 is

Hmmm. I'm less sure that javascript application developers will
want/get the point of 5969 but let's put it in and not debate
that now.

But in any case, I'd like us not to extend the list too much or
include things that might be perceived as arcane. I suspect that
getting the idea of a such an API accepted will require that it
be quite simple to use and understand.

S.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 27 Apr 2011 20:44:52 +1200

Carl Wallace <[email-masked]> writes:

>Add support for providing path validation algorithm inputs and receiving path
>validation algorithm outputs.  It probably wouldn't hurt to try to break
>reliance on unconstrained trust anchors in a new API too.

As we slowly move towards reinventing CDSA in Javascript, might I suggest:

- Encrypt and decrypt a blob in CMS or PGP format.
- MAC/Verify a blob in CMS or PGP format (actually you'd need CMS for this).
- Salted-iterated-hash a password.

Then see how things go with that, and if it's necessary to go any further.

Peter.

---

From: Nico Williams <[email-masked]>
Date: Thu, 28 Apr 2011 16:19:46 -0500

> o Support extracting keys from TLS sessions ala RFC 5176;

Please add:

 o Support for extracting channel bindings from TLS connections (see RFC5929);

Also, practically every major OS, if not every major OS, has a native
SASL and GSS-API implementation (or SSPI, which, for my purposes is
about the same).  It'd be nice to expose a standard interface to those
via JavaScript.  (See my GSS-REST paper that I submitted to the same
workshop, and which I posted here yesterday.)

> o Support for Cryptographic Message Syntax (CMS).

Nico
--

---

From: Sean Turner <[email-masked]>
Date: Thu, 28 Apr 2011 17:33:44 -0400

Nico,

It made it in the version we submitted last night.

spt

On 4/28/11 5:19 PM, Nico Williams wrote:
> On Tue, Apr 26, 2011 at 8:00 AM, Sean Turner<[email-masked]>  wrote:
>> Greedy Goals
>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Apr 2011 18:25:58 -0400

If I missed anything, please let me know -- I was working on it late
last night and might have failed to incorporate all comments. Perhaps I
can re-submit if needed.

Peter

---

From: Nico Williams <[email-masked]>
Date: Thu, 28 Apr 2011 18:22:18 -0500

> last night and might have failed to incorporate all comments. Perhaps I

I'd word the item about channel binding slightly differently:

 o Extraction of TLS channel bindings (see RFC5929)

Note that developers can use the TLS extractor and still get close to
RFC5056 channel binding semantics.  I'd rather developers used RFC5929
instead of the TLS extractor though, except where they absolutely need
to extract shared secret key material.  Which brings me to...

...I'm afraid that we could giving developers a lot of rope and not
much instruction in its use.  I have no objection of any kind to
giving developers all this rope (we don't have much choice anyways, as
they will get it with or without our approval).  But since developers
will likely be doing things that amount to security mechanism
composition, it'd be quite useful to take this chance to educate them,
via your W3C audience as to the value of channel binding as a
composition design and analysis technique.

I would also very much like off-the-shelf security mechanisms made
available to developers, for obvious reasons.  Besides the obvious
reasons there's also this one: browser chrome can be aware of and help
manage identities/credentials for such mechanisms, whereas mechanisms
implemented in random scripts cannot provide that level of
integration.

Nico
--

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 29 Apr 2011 23:31:51 +1200

>Please add:

That's it, it's doomed.  You may as well just take the CDSA spec [0] and add a
Javascript wrapper for it, given that it now includes pretty much everthing,
including at least two different styles of kitchen sink.

Peter.

[0] This being the most elephantine crypto API I know of, with (from memory,
    before it collapsed under its own gravitational field) 1,000 pages of
    documentation and 250MB of code.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Apr 2011 12:36:46 +0100

On 29/04/11 12:31, Peter Gutmann wrote:
> That's it, it's doomed.  

That's early to call it, even for you Peter:-)

If this got traction, then there'd be some interplay between
various interested folks, not sure where, but I bet that one
of the first things that'd have to be done is make it simple
for web developers, which would be a good thing IMO.

If it starts being CDSA-like, my name won't be attached at
least!

S.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 29 Apr 2011 23:46:59 +1200

Stephen Farrell <[email-masked]> writes:

>I bet that one of the first things that'd have to be done is make it simple
>for web developers

In that case it'd need to have an API built around things like "protect a
password", "wrap a message", and one or two others, something a bit like what
I suggested earlier.  How many web developers are going to even know what PKI
path validation and TLS channel bindings are, let alone want to touch them
with a barge pole?  The current proposal seem entirely tuned to meeting the
needs of security geeks, and totally alien for web developers.

Peter.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 29 Apr 2011 06:48:56 -0700

> needs of security geeks, and totally alien for web developers.

Why does such an API need to be just one (crypto primitives) or the other (common uses of web developers)? Why not an API that has both low-level and high-level calls? I know web developers who could use either.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Fri, 29 Apr 2011 10:14:15 -0500

On Fri, Apr 29, 2011 at 6:31 AM, Peter Gutmann
<[email-masked]> wrote:
> That's it, it's doomed.  ...

I want to agree, but can't.  There's two big differences between
developers using what rope they have to implement cryptographic
protocols and their using off-the-shelf ones: a) they're bound to
screw it up if they implement their own, b) there can't be any decent
browser chrome integration if they implement their own crypto
protocols.

(b) is the user noticeable difference.  (a) sucks too.

Of course, it's much easier to just give someone rope.  If that was
your point, well, I agree :)

>                     ...  You may as well just take the CDSA spec [0] and add a

Why not say the same thing about PKI, TLS, SASL, GSS, Kerberos, IKE,
SSH, ...?  They're all complex enough for that complaint.  Oh, that's
right: those are actually being used, and widely so :)

The paper in question isn't asking for new or never-used frameworks,
nor new primitives.  It's asking for JavaScript interfaces to
_existing_ frameworks (e.g., PKI) and primitives.  That's NOT a lot to
ask for.  (Does something like SWIG exist for ECMAScript
implementations?)

Nico
--