Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
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
1  
@CodesInChaos - Seems you're correct, this article states so: networkworld.com/news/2012/081512-nist-tls-261670.html –  Noordung 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 Answers 2

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

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.