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.

Average Rating: 4.7 out of 5 based on 214 user reviews.

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.

Average Rating: 4.8 out of 5 based on 219 user reviews.

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/

Average Rating: 4.9 out of 5 based on 165 user reviews.

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 🙂

Average Rating: 4.9 out of 5 based on 228 user reviews.

May 6th, 2011

This is sorta old news at this point, the publication was announced on 27 April 2011. Bil Corry and I wrote about the spec in early March (acknowledging the many contributors) when it was approved as ‘proposed standard’ and en-queued to the RFC Editor, and others have written about it (in detail) now that the RFC is actually published, so I’ll just point to ’em here…

Daniel Stenberg – The cookie RFC 6265 (english)
http://daniel.haxx.se/blog/2011/04/28/the-cookie-rfc-6265/

St̩phane Bortzmeyer РRFC 6265: HTTP State Management Mechanism (french)
http://www.bortzmeyer.org/6265.html

Joachim Str̦mbergson РCookie-RFCn 6265 (swedish)
http://secworks.se/2011/04/cookie-rfcn-6265/

It feels good to get that out the door!

Average Rating: 4.5 out of 5 based on 156 user reviews.

April 5th, 2011

RFC6125TLS/SSL Server Identity Check” (aka “TLS Server ID Check“, “SSL Server ID
Check
“, “TLS/SSL Server ID Check“, “SSL Server ID“) is now available:

Representation and Verification of Domain-Based Application Service
Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)


http://tools.ietf.org/html/rfc6125

Alas, we messed up by not including this “short form” title directly in the spec:

TLS/SSL Server Identity Check

But hopefully people will know what spec is meant if someone uses that short-form title.

I’ve written about the spec and its background before:

of TLS/SSL Server Identity Checking

Although we produced the spec without a formal working group, many people contributed to it one way or another. From the Contributors and Acknowledgments sections:

The following individuals made important contributions to the text of this document: Shumon Huque, RL ‘Bob’ Morgan, and Kurt Zeilenga.

The editors and contributors wish to thank the following individuals for their feedback and suggestions: Bernard Aboba, Richard Barnes, Uri Blumenthal, Nelson Bolyard, Kaspar Brand, Anthony Bryan, Scott Cantor, Wan-Teh Chang, Bil Corry, Dave Cridland, Dave Crocker, Cyrus Daboo, Charles Gardiner, Philip Guenther, Phillip Hallam-Baker, Bruno Harbulot, Wes Hardaker, David Harrington, Paul Hoffman, Love Hornquist Astrand, Henry Hotz, Russ Housley, Jeffrey Hutzelman, Cullen Jennings, Simon Josefsson, Geoff Keating, John Klensin, Scott Lawrence, Matt McCutchen, Alexey Melnikov, Subramanian Moonesamy, Eddy Nigg, Ludwig Nussel, Joe Orton, Tom Petch, Yngve N. Pettersen, Tim Polk, Robert Relyea, Eric Rescorla, Pete Resnick, Martin Rex, Joe Salowey, Stefan Santesson, Jim Schaad, Rob Stradling, Michael Stroeder, Andrew Sullivan, Peter Sylvester, Martin Thomson, Paul Tiemann, Sean Turner, Nicolas Williams, Dan Wing, Dan Winship, and Stefan Winter.

Thanks also to Barry Leiba and Ben Campbell for their reviews on behalf of the Security Directorate and the General Area Review Team, respectively.

The responsible Area Director was Alexey Melnikov.

(i.e. 59 people besides PeterSA and myself (wow))

Average Rating: 4.6 out of 5 based on 225 user reviews.

March 15th, 2011

As I’ve previously mentioned, I’ve been working on a specification for “TLS/SSL Server Identity Checking” along with Peter Saint-Andre.

We’ve now heard back from the RFC Editor, and we’re in the so-called “AUTH48 state” where we, the spec’s authors/editors, work with the RFC Editor folks to turn the Internet-Draft into a RFC.

At this point we know the RFC number-to-be: 6125.

So, we’re close to getting this thing out the door, whew. 🙂

Average Rating: 4.7 out of 5 based on 242 user reviews.

March 7th, 2011

There’s been various fundamental issues with “HTTP cookies” for ages, e.g. technically and policy-wise (i.e. privacy). The two extant formal specifications of cookies, IETF RFCs 2109 and 2965, as well as the original informal and incomplete “Netscape cookie spec”, have not been implemented uniformly across browsers and servers. Thus how cookies are actually constructed, parsed, and used in practice has been essentially technical folklore. Anyone wanting to craft a new browser or some other application or tool that needs to consume or send cookie headers had to reverse engineer how the browsers were actually doing it as there wasn’t (until now) an accurate specification an implementer could use for reference. This has led to divergence on edge-cases for cookies within various browsers, servers, and other tools.

We’ve been working with browser, server, and web app folk in an IETF working group, “httpstate“, to rectify this, and the draft spec was recently approved for publication as an IETF RFC at the “Proposed Standard” maturity level. This spec differs from the prior specs in that it specifies how cookies are actually used on the Internet today. Anyone crafting a new client or server can implement the spec and have an interoperable implementation as a result.

This is great in that getting this finally explicitly documented will be a key underlying piece of moving “the Web“, and the wider Internet its built upon, on towards its next stage(s). Hopefully, browsers and servers can now converge their “cookie behaviors” 🙂

Our more detailed blog post (which includes some history) is here..

‘HTTP State Management Mechanism’ to Proposed Standard
http://www.thesecuritypractice.com/the_security_practice/2011/03/http-state-management-mechanism-to-proposed-standard.html

=JeffH sez check it out 🙂

Average Rating: 5 out of 5 based on 286 user reviews.

March 7th, 2011

We have a blog post over at my work cohort’s blog, w.r.t. a recent preso we gave, here’s the link…

Web (In)Security: Remediation Efforts – Status and Outlook
http://www.thesecuritypractice.com/the_security_practice/2011/03/web-insecurity-remediation-efforts-status-and-outlook.html

Check it out 🙂

Average Rating: 4.4 out of 5 based on 176 user reviews.

February 23rd, 2011

Susan Landau, with whom I’ve had the pleasure of working and co-authoring some documents (e.g.: a, b, c), has new book that’s now available: Surveillance or Security? The Risks Posed by New Wiretapping Technologies.

Additionally, NPR ran an All Things Considered piece yesterday on the wiretapping topic and interviewed Susan for it.

Also, she’s blogging (here) at the the Huffington Post on these and overall security/policy topics.

=JeffH sez check it out 🙂

Average Rating: 5 out of 5 based on 204 user reviews.