This updated version of the ticket requests draft incorporates feedback we 
received in Montreal. Specifically, it removes the post-handshake request and 
response messages in favor of a simpler mechanism by which clients indicate 
their desired ticket count in a CH extension. Time permitting, we’d like a few 
minutes to discuss the latest changes and gauge WG interest in the draft.

Thanks,
Chris (chair hat off)

> Begin forwarded message:
> 
> From: [email protected]
> Subject: New Version Notification for draft-wood-tls-ticketrequests-01.txt
> Date: October 13, 2018 at 6:05:44 PM PDT
> To: Christopher Wood <[email protected]>, David Schinazi 
> <[email protected]>, Tommy Pauly <[email protected]>, "Christopher A. Wood" 
> <[email protected]>
> 
> 
> A new version of I-D, draft-wood-tls-ticketrequests-01.txt
> has been successfully submitted by Christopher A. Wood and posted to the
> IETF repository.
> 
> Name:         draft-wood-tls-ticketrequests
> Revision:     01
> Title:                TLS Ticket Requests
> Document date:        2018-10-13
> Group:                Individual Submission
> Pages:                6
> URL:            
> https://www.ietf.org/internet-drafts/draft-wood-tls-ticketrequests-01.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/
> Htmlized:       https://tools.ietf.org/html/draft-wood-tls-ticketrequests-01
> Htmlized:       
> https://datatracker.ietf.org/doc/html/draft-wood-tls-ticketrequests
> Diff:           
> https://www.ietf.org/rfcdiff?url2=draft-wood-tls-ticketrequests-01
> 
> Abstract:
>   TLS session tickets enable stateless connection resumption for
>   clients without server-side per-client state.  Servers vend session
>   tickets to clients, at their discretion, upon connection
>   establishment.  Clients store and use tickets when resuming future
>   connections.  Moreover, clients should use tickets at most once for
>   session resumption, especially if such keying material protects early
>   application data.  Single-use tickets bound the number of parallel
>   connections a client may initiate by the number of tickets received
>   from a given server.  To address this limitation, this document
>   describes a mechanism by which clients may specify the desired number
>   of tickets needed for future connections.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls

Reply via email to