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

[Ballot comment]
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.

[Ballot discuss]
I want to discuss the apps issue mentioned in my comment during the IESG
call.  My intention is to clear this DISCUSS during the IESG call unless
others on the IESG feel the harm of modest delay to address the issue I
raised is worth the potential improvement.

[Ballot comment]
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

IANA Last Call Comments:

NOTE: The IANA Considerations section isn't completely
clear that there's nothing to do. It should probably add
a sentence that the assignments were made in RFC4507
and don't need to be made again.

As described in the IANA Considerations section, we
understand this document to have NO IANA Actions.