TLS already contains a certificate caching mechanism ( https://tools.ietf.org/html/rfc7924).
A more general scheme looks like it ought to perform better against new sites, though I've also heard some questions about whether the additional complexity tradeoff is worth it. If someone wanted to write a certificate compression draft for TLS, this certainly is something that would be worth examining. I don't see any reason we would need to limit/tie it to TLS 1.3 however. -Ekr On Sat, Nov 26, 2016 at 5:54 PM, Alessandro Ghedini <alessan...@ghedini.me> wrote: > Hello, > > not sure if this has been discussed before (apologies if it has). > > QUIC mandates that certificate chains be gzip compressed in order to > reduce the > amount of bytes transmitted during full handshake. > > The QUIC crypto document says: > > Any remaining certificates are gzip compressed with a pre-shared > dictionary > that consists of the certificates specified by either of the first two > methods, and a block of common strings from certificates taken from the > Alexa top 5000. > > https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_ > L2f5LTaDUDwvZ5L6g/edit#heading=h.fgd4sj5avil0 > > Has anyone though about including something like that in TLS 1.3? > > Given that certificates usually take up most of the bytes exchanged during > a > full handshake it seems this could be useful, but I don't know if in > practice > the benefits are worth the added complexity. Thoughts? > > Cheers > > _______________________________________________ > 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
