Transport Layer Security (TLS) Session Resumption without Server-Side State
Note: This ballot was opened for revision 01 and is now closed.
(Jari Arkko) Yes
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
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