On Tue, May 2, 2017 at 9:45 PM, Colm MacCárthaigh <c...@allcosts.net> wrote: > > On Tue, May 2, 2017 at 5:51 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> > wrote: >> >> .Some choices are driven by practical engineering considerations. >> >> The ticket lifetime is likely to be considerably longer than the >> replay clock window. The server should indeed reject replays, >> but if it is able to flush the replay cache faster, it may be able >> to handle that job a lot more efficiently under load. > > Good point! It's also common for caches to implement LRU, where a shorter > lifetime is better. > >> What is a likely ticket lifetime for a server that supports 0-RTT >> (let's assume an HTTP server)? > > I'm going to guess that providers will set it as high as they can ... every > little helps. So 7 days.
It seems like this would follow the same policies for session management and/or authentication and authorizations. If its low value data (like a GMail account), then let it live longer, like weeks. If its high value data (like executive compensation, mergers and acquisitions or pending litigation), then its probably shorter, like hours to days. What's the polyfill that allows data sensitivity levels to trickle down into the transport layer? Jeff _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
