On Fri, Apr 22, 2016 at 6:49 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> > The list will likely grow over time much like it has in the past. My > guess > > is that most clients will simply reuse the existing session cache from > TLS > > 1.2. All state will be remembered. > > If I was to implement this, I would implement it as dynamic provisioning of > PSKs (because that it is) with fixed-schema database table (not SQL tho) > for > PSK data. And then never resume sessions but treat every connection as in- > depedently as possible (PSK priorized over GDHE-CERT). > > That is, anything remembered should only be used for 0-RTT interpretation > anything else looks to be a nasty trap (at least don't assume it will be > implemented correctly!).. > > Also thanks for flashbacks from realizing that TLS 1.2 session resumption > is > much nastier than what I thought, and I already considered it nasty enough > to > put choice DJB quote about TLS as code comment... I think we're in agreement now. Imagine all that code dedicated to session state interaction with extensions, and now instead of a clean slate TLS 2.0, do a TLS 1.3 that is as different as possible from TLS 1.2 without actually requiring rewriting the code... It will be awesome to have the speed of 0-RTT in TLS 1.3, but I look forward to the TLS 2.0 effort. Bill
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
