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

Note: This ballot was opened for revision 01 and is now closed.

(Jari Arkko) Yes

Comment (2007-09-06)
No email
send info
It seems that Appendix A does not list all the changes
from RFC 4507. The diff is available here:

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc4507.txt&url2=http://tools.ietf.org/id/draft-salowey-tls-rfc4507bis-01.txt

And there are a number of changes, including additional requirements on including specific messages in a hash (Section 3.3), moving from SHA1 to SHA256, etc.

(Tim Polk) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Sam Hartman) No Objection

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Chris Newman) (was Discuss, No Objection, Discuss) No Objection

Comment (2007-09-06)
No email
send info
Apps-level issue:

If an application performs user-level authentication subsequent to
initiation of the TLS tunnel (e.g. via GSSAPI or SASL), it would be
possible for the application to trigger a TLS-level renegotiation that
includes a NewSessionTicket embedding information about the app-level
authentication.  Alternatively, the application could have a mechanism
to bind the user-level authentication to a given session ticket
(although this would involve server state).  Then on re-connection,
the application could use app-level mechanisms to automatically resume
the user session (e.g. IMAP PREAUTH or SASL EXTERNAL).  It's not clear
to me if this is a good/bad idea, what the security risks would be, or
if TLS stacks should be advised to include APIs to facilitate such use
of the mechanism.  This document is silent on such interaction with
applications.  Were this a first version, I'd ask for this issue to be
considered and addressed if there was consensus.  But I don't want to
delay an obvious bugfix to an already published RFC.

Nits:

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

   The server uses an zero-length SessionTicket extension to indicate to
                   ^^
                   a

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund No Objection