Subject: [websec] Fwd: [apps-discuss] Position Paper for W3C Identity in the Browser Workshop

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

Just FYI, please reply on the apps-discuss list if you have feedback.

-------- Original Message --------
Subject: [apps-discuss] Position Paper for W3C Identity in the Browser
Workshop
Date: Tue, 26 Apr 2011 11:12:02 -0600
From: Peter Saint-Andre <[email-masked]>
To: [email-masked] <[email-masked]>
CC: Sean Turner <[email-masked]>

Folks, over on the SAAG list, Sean Turner and Stephen Farrell have
posted a draft position paper for the upcoming W3C Workshop on Identity
in the Browser:

http://www.ietf.org/mail-archive/web/saag/current/msg03201.html
http://www.w3.org/2011/identity-ws/

Because neither Sean nor Stephen will be able to attend the workshop, I
offered to help them by co-authoring the position paper and presenting
about the topic if the proposal is accepted.

Since this proposal straddles the line between apps and security, I
figured it would be good to get feedback from the AppsArea community
before we submit the proposal (the deadline is tomorrow, sorry about the
late notice).

Your feedback is welcome.

Thanks!

Peter

###

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 not 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)

###

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