RFC6797 “HTTP Strict Transport Security (HSTS)” is published

November 21st, 2012

RFC6797 “HTTP Strict Transport Security (HSTS)” is now available.

It’s been a long haul to get to this point, and I thank all the folks who have contributed along the way, i.e. Collin Jackson and Adam Barth who had the original idea [ForceHTTPS] and co-authored the spec, and all the other folks who contributed to its gestation (from the Acknowledgements appendix):

The authors thank Devdatta Akhawe, Michael Barrett, Ben Campbell,
Tobias Gondrom, Paul Hoffman, Murray Kucherawy, Barry Leiba, James
Manger, Alexey Melnikov, Haevard Molland, Yoav Nir, Yngve N.
Pettersen, Laksh Raghavan, Marsh Ray, Julian Reschke, Eric Rescorla,
Tom Ritter, Peter Saint-Andre, Brian Smith, Robert Sparks, Maciej
Stachowiak, Sid Stamm, Andy Steingrubl, Brandon Sterne, Martin
Thomson, Daniel Veditz, and Jan Wrobel, as well as all the websec
working group participants and others for their various reviews and
helpful contributions.

Thanks to Julian Reschke for his elegant rewriting of the effective
request URI text, which he did when incorporating the ERU notion into
the updates to HTTP/1.1 [HTTP1_1-UPD]. Subsequently, the ERU text in
this spec was lifted from Julian’s work in the updated HTTP/1.1
(part 1) specification and adapted to the [RFC2616] ABNF.

See also the Wikipedia HSTS article for various other information about HSTS and deploying it.

=JeffH sez check it out :)

HTTP Strict Transport Security (HSTS) Approved as Proposed Standard RFC

October 2nd, 2012

As I’d noted back in July, the draft HSTS spec was in IETF-wide last call, from which we exited in August with various helpful comments. We applied summore elbow grease to the ol’spec and shipped it to the IESG (Internet Engineering Steering Group) for further inspection, received more good comments, subsequently applied more tweaks and polish, and voila(!), this morning we have this little missive in our email…

[websec] Protocol Action: ‘HTTP Strict Transport Security (HSTS)’ to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)

At this point, the draft HSTS spec will be placed on the RFC Editor’s queue (which is fairly large & diverse) and will emerge in several weeks as an RFC with a proper RFC number and all.

Many thanks to all who’ve contributed, especially to Collin Jackson & Adam Barth for originally inventing this approach (which they dubbed “ForceHTTPS“).

=JeffH

PS: The Wikipedia HSTS entry has a consolidated specification history as well as information regarding implementation and deployment.

The Death of the Internet?

July 24th, 2012

The deliberately provocative title of this post is also the deliberately provocative title of a new book, conceived and edited by colleague Markus Jakobsson, that’s now available:

The Death of the Internet
http://onlinelibrary.wiley.com/book/10.1002/9781118312551

The book analyzes the overall problem of criminal activity on the Internet—namely fraud—and its ensuing damage. It then goes on to examine how criminals profit, how the Internet’s systems work and fail, and issues in the mobile and physical worlds. It concludes by outlining various solution proposals, examining the crucial role of user experience, and poses a set of guiding questions to ask ourselves as we go forward. The essential premise is that we collectively need to keep fraud under control or we risk losing the open freely generative Internet as we know it.

The book sections are authored by a broad cross-section of Web and Internet security researchers and engineers from across academia and industry. They collectively present a detailed multifaceted picture of the spectrum of issues and solutions.

I and Andy Steingruebl co-authored a chapter entitled “Web Security Remediation Efforts” describing aspects of overall web security issues and on-going efforts in, for example, the W3C and IETF to address them.

=JeffH sez check it out :)

RLBob: SUNet ID and the Registry and Directory Infrastructure

July 14th, 2012

Primary among RL “Bob” Morgan‘s (aka “RLBob”) many contributions during his time at Stanford Networking Systems, was being a key visionary and instigator behind the Stanford University SUNet ID project, as well as the underlying Registry and Directory Infrastructure.

The main use cases RLBob latched onto in the early 1990s were having a centralized institution-wide authentication infrastructure, and a “flat” email address namespace. Both use cases drive requirements for having a centrally-maintained yet delegated-management notions of person naming.

At that time, all email addresses at Stanford were relative to some particular system or host. So, you had to remember whether some Stanford correspondent’s email address was @forsythe.stanford.edu, or @leland.stanford.edu, or @networking.stanford.edu, or @whatever.stanford.edu. Additionally, one’s online name, or names, were invariably driven by either/both of the unix-based academic computing environment (up to 8 alphanumeric characters) or/and the administrative mainframe-based environment (a often impenetrable six-alpha-character-with-dot concoction, such as “bl.foo”). Good luck with having online apps decently leverage your actual meatspace natural name(s) in this sort of environment.

Now, this of course was a burden for users. What if you changed departments? What if you were affiliated with more than one department? Well, you had more than one email address and it was pretty much up to you to figure out how to deal with that (this is of course just one aspect of the raft of issues we had at the time with the existing, essentially ad-hoc system).

RLBob was always very conscious of usability for the common non-computer-literate folk. He believed strongly in the value to the individual of having one’s online persona map reasonably to one’s offline meatspace persona. To him this meant figuring out technologies, policies, and procedures such that one’s natural name(s) could be represented and leveraged online as (ahem) naturally as possible. Also, that changes to one’s natural names (as necessitated by real world events/needs) could be accommodated reasonably.

So, to try to shorten a quite long, nuanced, multi-faceted story, here’s the early 1996 versions of the requirements and design documents RLBob crafted. We used these docs to inform the overall multi-phase SUNet ID et al project (which was well along by that time)..

sunet.id.requirements
http://kingsmountain.com/doc/Morgan-sunet.id.requirements-1996-03-01.txt

sunet.id.design
http://kingsmountain.com/doc/Morgan-sunet.id.design-1996-03-01.txt

The modern present-day, user-facing SUNet ID description is here..

SUNet IDs
http://itservices.stanford.edu/service/accounts/sunetids

In the first phase of the project (as I recall), we crafted SUNet IDs (featuring various name forms, e.g., short and long) and enabled sunetid@stanford.edu email delivery. However, this did not account for all the various institutional repositories of identity data, and did not provide for mapping between them.

So in the second phase of the project, RLBob championed the notion of a Registry, having this definition..

“A registry is a service that serves the needs of applications for coordinated maintenance of identity information about a class of business objects.”

..E.g., some classes are: People, services, groups. A registry is a transaction-oriented service. Client applications use one mostly to enter and update information, I.e. a registry is write- and update-oriented. Read-oriented access is typically handled by other components of the overall system, e.g. the Directory.

And thus the “Registry and Directory Infrastructure” notion took shape.

Below is a case-history presentation about this system that I crafted for a conference in early 1999. RLBob, in his Enterprise Architect role, made significant contributions to the overall thinking behind the entire system, as well as key detailed design aspects. Note also that this was a large project with many contributors crafting various aspects, including architecture, of the overall multi-faceted system (see especially the Acknowledgements on slides 23 & 24)..

Stanford Registry & Directory Infrastructure
http://kingsmountain.com/doc/StanfordRegistryAndDirectoryCaseHistory-1999-05-11.pdf

I am honored to have participated in this project and and been part of such a talented team.


See also the RLBob tribute page, as well as my other recent post about him and his recent passing..

RLBob Migrates to The Cloud
http://identitymeme.org/archives/2012/07/13/rlbob-migrates-to-the-cloud/

Angela Lee Memorial Hike

July 14th, 2012

There will be a memorial hike in honor of Angela Lee, the late wife of my (and RLBob‘s) colleague Rob Riepel (of Stanford Networking Systems), on Sat 11-Aug-2012, outside of Lone Pine, CA.

Angela was another (relatively) recent victim of cancer, left us at far too young of age, and is sorely missed. See Pages 3 & 4 of of the Institute for Stem Cell Biology and Regenerative Medicine‘s (where she worked) September 2011 newsletter for an in-depth obituary.

See this page for details of the hike and pics of its beautiful high-country environs.

Given the nature of her work, perhaps Angela and RLBob (given the modus operandi of his recent unfortunate cloud migration) will meet Cloud-side — they apparently, and entirely coincidentally, have a fair bit in common.

RLBob migrates to The Cloud

July 13th, 2012

A day or two earlier this week, RL “Bob” Morgan, a long time colleague and friend of many of us in the Higher-Ed, Identity, directory, University of Washington, Stanford, IETF, OASIS, Internet2 Middleware communities passed away due to complications from his long bout with cancer and treatments thereof.

Bob made positive contributions wherever he traveled and to whatever he participated in (notably his beloved family). I personally benefited greatly from his friendship and mentoring, and am going to miss him so very terribly.

Various of his colleagues/friends had been joking online with him about whether “this time”, his second stem cell transplant, was “an OS re-install” or whatever, and so he definitively cleared it up for all of us in his imitable fashion, with this blog post entitled “Metaphorically on “day zero” (21-Jun-2012)..

Just to clear this up, for all you computer people.
Last time was “re-install OS and restore from backup”.
This time is “install a different OS”.
Next time is “migrate to the cloud”.
Got it?

Unfortunately, “this time” and “next time” got conflated, and RLBob indeed has migrated to The Cloud. :-(

Hey big guy, are you gonna help them deploy SCIM up there?

Tributes to RL “Bob” can be found (and posted) here:

https://spaces.internet2.edu/display/rlbob/Home

Finishing up the HSTS spec — IETF-wide Last Call

July 11th, 2012

We’re in the near-final push here on getting the HTTP Strict Transport Security (HSTS) draft spec to be published as an RFC.

The most recent draft version (revision -11 as of this writing) is here..

https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec

And the IESG‘s announcement for IETF-wide Last Call is here..

https://www.ietf.org/mail-archive/web/ietf-announce/current/msg10470.html

We’re coming around the last corner and the finish line is in sight!

See also the Wikipedia entry for HSTS — it has info on the spec’s history, applicability, deployment, and implementations.

Internet Governance in the Crosshairs

July 2nd, 2012

The Internet has historically largely run in an open and cooperative fashion, speaking very broadly of course. The implication being that it has largely been unregulated in an international sense, and not subject to the recommendations and policies fostered by formal nation State-level organizations such as the ITU-T, which is a specialized agency of the UN. Historically, various forms of telegraph and voice communications (radio and wireline) have been subject to this, but the Internet is a fundamentally different beast.

Various actors are apparently presently maneuvering in a Pynchonian attempt to not-so-subtly add language to the ITU-T’s International Telecommunication Regulations (ITRs) — which are up for review and revision in Dec 2012 at the World Conference on International Telecommunications (WCIT) — such that the Internet either explicitly or implicitly falls under the purview if the ITRs, thus the ITU-T.

Of course this is all extremely complicated, infested with swarms of acronyms, and has implications for how Internet governance policies and technical standards development plays out in the longer term. Thus it has implications for how the Internet evolves as a platform for international communication and commerce — for individuals, businesses, organizations, governments, you-name-it.

Others are paying direct attention to these developments and are blogging extensively about it. A modest selection is:

There’s more sources out there, but hopefully that will provide you gentle readers with good starting points.

Seems we can all just GetYourCensorOn ..or we can go after SOPA and ProtectIP/PIPA

December 17th, 2011

For illustrations of potential end-user downsides of SOPA and ProtectIP/PIPA, and to do something about them (yes, you), see..

GetYourCensorOn
http://getyourcensoron.com/

Stop American Censorship
http://americancensorship.org/

For what a bunch of folks involved in engineering the Internet think, see..

An Open Letter From Internet Engineers to the U.S. Congress
December 15, 2011 | By Parker Higgins and Peter Eckersley
https://www.eff.org/deeplinks/2011/12/internet-inventors-warn-against-sopa-and-pipa

For some further commentary, see the below (this is just some highlights, you don’t have to look far to find a bunch more out there)..

Some Data On How Much The Big Media Firms Are Donating To SOPA/PIPA Sponsors
http://www.techdirt.com/articles/20111203/00494716961/some-data-how-much-big-media-firms-are-donating-to-sopapipa-sponsors.shtml

YouTube rejects UMG demand – Megaupload Mega Song returns
http://www.nnsquad.org/archives/nnsquad/msg06203.html

SOPA-Rope-a-dope (by Stewart Baker)
http://volokh.com/2011/12/14/sopa-rope-a-dope/

Technical Comments on Mandated DNS Filtering Requirements of H. R. 3261 (“SOPA”)
http://www.circleid.com/posts/20111211_technical_comments_on_mandated_dns_filtering_requirements_sopa/

‘Combating Cybercrime’ whitepaper

May 8th, 2011

My colleagues Michael Barrett, Andy Steingruebl, and Bill Smith recently authored a whitepaper..

Combating Cybercrime: Principles, Policies, and Programs

..and Michael blogged an executive summary here.

The executive executive summary is:

Technical measures alone cannot significantly address the cybercrime trends, we believe action is needed, and are proposing a multi-faceted regulatory approach. We’re occasionally asked to “list the three things you want us to do.” And while we’re hesitant to say any of these initiatives is more important than any other, in general, we list:

Also, Dave Piscitello, ‘The Security Skeptic’, reviewed the whitepaper here.

=JeffH sez check it out :)