Skip to main content

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

Yes

(Tim Polk)

No Objection

Lars Eggert
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Sam Hartman)

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

Lars Eggert No Objection

(Jari Arkko; former steering group member) Yes

Yes (2007-09-06)
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; former steering group member) Yes

Yes ()

                            

(Chris Newman; former steering group member) (was Discuss, No Objection, Discuss) No Objection

No Objection (2007-09-06)
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

(Cullen Jennings; former steering group member) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Ward; former steering group member) No Objection

No Objection ()

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Lisa Dusseault; former steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sam Hartman; former steering group member) No Objection

No Objection ()