What problem are you trying to solve here? The forward secrecy properties of 0-RTT data in PSK mode are tied to the lifetime of the resumption secret, not a long-lived secret like the private key. If we limit the maximum lifetime of a given session ticket (say to 7 days as previously proposed on this mailing list) and recommend a similar lifetime for session ticket encryption keys, then what is the forward secrecy risk?
> On Mar 16, 2016, at 9:45 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > >> On Wed, Mar 16, 2016 at 08:12:48AM -0400, Colm MacCárthaigh wrote: >> On Wed, Mar 16, 2016 at 4:17 AM, Ilari Liusvaara <ilariliusva...@welho.com> >> wrote: >>> >>> - Duplication of 0-RTT data into 1-RTT data of _different_ connection. >> >> I think using a different content type solves this; the early data is >> illegal in the 1-RTT phase and the content type would distinguish it. > > Nope, this can not be realistically solved, _even_ with server state > (the 0-RTT to 0-RTT duplication is unsolveable without state, but can > be solved with server state). > > >> As an aside: an application protocol where latency is so sensitive that >> 0RTT is attractive would hardly have its own back-and-forth with banners in >> the first place. > > The problem is that such banners would not be bound to the TLS connection > in any way, which causes problems (TLS has no facility to transport data > from application inside extension). > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
