Transport Layer Security (TLS) Session Resumption without Server-Side State
RFC 5077

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Transport Layer Security (TLS) 
         Session Resumption without Server-Side State' to Proposed 
         Standard 

The IESG has approved the following document:

- 'Transport Layer Security (TLS) Session Resumption without Server-Side 
   State '
   <draft-salowey-tls-rfc4507bis-02.txt> as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-salowey-tls-rfc4507bis-02.txt

Ballot Text

Technical Summary
 
This document obsoletes RFC 4507 [RFC4507] to correct an error in the
encoding that caused the specification to differ from deployed	
implementations.  This update to RFC 4507 aligns the document with
this currently deployed implementations.
 
Working Group Summary
 
This document is an individual submission, and not the product of any
IETF working group.
 
Protocol Quality
 
Tim Polk reviewed this document for the IESG.  Multiple implementations
of this specification exist.

Note to RFC Editor

- Section 3.1, next to last paragraph:
OLD
	the server does not wish issue a new ticket and therefore does not ...

NEW
	the server does not wish to issue a new ticket and therefore does not ...




- Section 3.2, third paragraph first sentence:
OLD
	The server uses an zero-length SessionTicket extension to indicate to ...




NEW
	The server uses a zero-length SessionTicket extension to indicate to ...


- Add to the end of Appendix A:
NEW
	In addition this documents makes a few additional changes to RFC
4507 including

	o Clarifying that the server can allow session resumption using
a ticket without issuing a new ticket in section in Section 3.1
	o Clarifying that the NewSessionTicket handshake message is
included in the hash generated for the Finished messages in Section 3.3
	o Recommending the use of SHA-256 for the integrity protection
of the ticket in Section 4
	o Clarifying that additional data can be included in the
StatePlaintext structure in Section 4

- In the authors' contact information for Hannes Tschofenig:
OLD
	EMail: Hannes.Tschofenig@siemens.com

NEW
	Email: Hannes.Tschofenig@nsn.com

RFC Editor Note