5

The document NIST Special Publication 800-52 Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations was retired without superseding it with a newer document.

In addition there is a Network World article that mentions the requirement of Mutual Auth TLS on Government websites and the possible depreciation of TLS 1.0.

  • I don't have the original document to refer to, but what was so egregious in this document that required its demise? Is NIST getting ready to pull the rug from under certain configurations of TLS?

  • What are the implications for the federal user concerning TLS moving forward?

makerofthings7
  • 50,488
  • 54
  • 253
  • 542
Drew Lex
  • 2,013
  • 2
  • 19
  • 24
  • There is no replacement for TLS. So I doubt TLS is going anywhere (except perhaps finally upgrading to 1.2). – CodesInChaos Mar 22 '13 at 17:01
  • 1
    Why does a single, expired document, which may have happened automatically, make you suspect this? – makerofthings7 Mar 22 '13 at 17:02
  • For all we know this documentation blip on the public network may be a result of Fiscal Cliff cutbacks. It's probably available elsewhere, or v2 is under delayed review. – makerofthings7 Mar 22 '13 at 17:04
  • Under "Archived Special Publications" http://csrc.nist.gov/publications/PubsSPArch.html Sp800-52 is the only document that has no "Superceded By:". I doubt there is an automatic cut-off. – Drew Lex Mar 22 '13 at 17:08
  • IMO the biggest change you'd could expect is them mandating TLS 1.2 or some changes to the allowed ciphersuites. Certainly not a whole new protocol. – CodesInChaos Mar 22 '13 at 17:11
  • 1
    @CodesInChaos - Seems you're correct, this article states so: https://www.networkworld.com/news/2012/081512-nist-tls-261670.html – TildalWave Mar 22 '13 at 17:50
  • 1
    +1 Tidalwave. This q has 30 views and without a single upvote It makes me think a revision is needed so it will attract a more logical audience. (e.g. not sound so alarmist, and more risk/logical driven) – makerofthings7 Mar 22 '13 at 18:44
  • 1
    @DrewLex I made edits to your question that may draw more attention to it. Please edit/revise as needed. – makerofthings7 Mar 22 '13 at 18:54

2 Answers2

7

It took nearly a year, but NIST has released this bulletin explaining the update and also providing the updated document for SP 800-52 Revision 1.

The answer to your question is expressed in the bulletin:

NIST published the original version of SP 800-52 in 2005, but withdrew it in March 2013 because the guideline had not yet been updated based on the new versions of TLS and known vulnerabilities. This new publication is the final version of SP 800-52 Rev. 1, which incorporates public comments to the draft version made in the fall of 2013.

Chief among the changes in SP 800-52 are the recommendations that government servers and clients move to TLS 1.1 and 1.2. It also recommends that they adopt cipher suites with NIST-approved algorithms to support 112-bit security strength and higher.

Ryan Fisher
  • 171
  • 1
  • 1
6

Updated: see Ryan Fisher's answer to this question, SP800-52 revision 1 was later released, and it's double the size of the original 2005 version. It was withdrawn because it lacked information on contemporary TLS versions and known security issues (i.e to prevent misinforming, until it could be updated).

It was not "retired" (or "expired"), it was "withdrawn", admittedly a minor semantic distinction. NIST have the following generality to say about that:

This page contains a list of withdrawn Special Publications (SPs) that have either been superseded by an updated SP or is no longer being supported and no updated version was released.

Since there  is  was no (evident) successor, it may be no longer supported. It's worth noting that its raison d'être is now no less than 17 years old.

I suggest the main motivation is the (selective) elimination of one or more of 3DES/TDEA, MD5 (which NIST have long disliked) or SHA-1. The official statement is 3DES is good until 2015 (or 2030), TLSv1.1 drops the mandatory TLSv1.0 cipher TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA in favour of TLS_RSA_WITH_3DES_EDE_CBC_SHA, and TLSv1.2 drops that in favour of TLS_RSA_WITH_AES_128_CBC_SHA.

TLS versions after TLSv1.0 still support MD5, but since SHA-1 is deprecated, and must go away for certain purposes this year, there are clear advantages to TLSv1.1 and later including less dependence on MD5/SHA-1 and better support for arbitrary cipher or hash functions by way of extensions.

(So, what CodesInChaos said, but with more handwaving, conjecture and hyperlinks ;-)

Community
  • 1
mr.spuratic
  • 7,977
  • 26
  • 37
  • 800-131A removes only _two-key_ TDEA in 2015; three-key (as used in SSL/TLS) was and is still accepted. 1.1 does not reduce dependence on MD5/SHA-1, 1.2 does as both answers at your link correctly say. (And in 2018 so does 1.3.) No extensions provide 'better support for arbitrary cipher' except in an indirect way encrypt-then-mac in 2014 which technically can apply back to 1.0 but was never TTBOMK implemented for anything but 1.2 and rarely even for that. Sigalgs extension in 1.2 only, not 1.1, supports more hashes, but they must be registered, which I would not call 'arbitrary'. – dave_thompson_085 Apr 27 '21 at 00:24