Transport Layer Security (TLS) Session Resumption without Server-Side State
draft-salowey-tls-rfc4507bis-01
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