Posts Tagged ‘TLS’

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

Wednesday, 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 :)

RFC6125 “TLS/SSL Server Identity Check” is published

Tuesday, April 5th, 2011

RFC6125TLS/SSL Server Identity Check” (aka “TLS Server ID Check“, “SSL Server ID
“, “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)

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

TLS/SSL Server Identity Check will be RFC6125

Tuesday, 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. :)

of TLS/SSL Server Identity Checking

Tuesday, February 1st, 2011

[ Update (23-Apr-2011): This spec was published as RFC6125 on 30-Mar-2011. See also this more recent post. ]

Aside from HSTS, which I’ve written about here earlier, I’ve also been working on a specification for “TLS/SSL Server Identity Checking” along with Peter Saint-Andre.

The basic summary is: you have a DNS domain name identifying some application service (aka “a server”) you wish to connect to over TLS/SSL, e.g. “”, and once you do so, how do you really know (and check) that the returned PKIX Certificate contains an identifier(s) that maps to the name of the application service you intended to interact with?

This turns out to be a fairly complex endeavor, and up to the present here, various protocol specs have either specified it on their own, or have referenced another spec that has addressed the problem. One such referenced spec is RFC2830, “Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security“, which I co-authored. So anyway, I got involved a few years back in trying to concoct a dedicated specification for how to do TLS/SSL server identity checking in an application protocol neutral fashion. Eventually, Peter Saint-Andre and I signed up to buckle down and make the spec a reality. Much of this work occurred during 2010.

The resulting internet-draft, draft-saintandre-tls-server-id-check, was approved on 20-Jan-2011 as a Proposed Standard RFC, and will be published as such in the next couple of months. It has this fairly precise but unwieldy title:

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)

In the spec (which has been referred to as “-tls-server-id-check” in various email discussion threads (e.g. see the list), we provide an appendix of extracts from various current RFCs that specify performing such a check. The hope is that, going forward, emerging specifications can simply reference (i.e. “re-use”), and profile if necessary, the -tls-server-id-check spec. In fact, there’s presently four Internet-Drafts in the RFC-Editor’s work queue that do just that.

=JeffH sez check it out :)