Hi Victor why don't you use RFC 7924: https://tools.ietf.org/html/rfc7924
This provides an even better "compression" ratio. Ciao Hannes On 03/06/2017 11:58 PM, Victor Vasiliev wrote: > Certificate compression has been discussed on this list briefly before, and > there was some interest in at least considering a draft for it. The > draft now > exists (co-authored by Alessandro and myself), and it can be found at: > > https://datatracker.ietf.org/doc/draft-ghedini-tls-certificate-compression/ > [ GitHub repo: https://github.com/ghedo/tls-certificate-compression ] > > The proposed scheme allows a client and a server to negotiate a compression > algorithm for the server certificate message. The scheme is purely > opt-in on > both sides. The current version of the draft defines zlib and Brotli > compression, both of which are well-specified formats with an existing > deployment experience. > > There are multiple motivations to compress certificates. The first one > is that > the smaller they are, the faster they arrive (both due to the transfer > time and > a decreased chance of packet loss). > > The second, and more interesting one, is that having small certificates is > important for QUIC in order to achieve 1-RTT handshakes while limiting the > opportunities for amplification attacks. Currently, TLS 1.3 over TCP > without > client auth looks like this: > > Round trip 1: client sends SYN, server sends SYN ACK > Here, the server provides its own random value which client will > have to echo in the future. > Round trip 2: client sends ACK, ClientHello, server sends > ServerHello...Finished > Here, ACK confirms to server that the client can receive packets and > is not > just spoofing its source address. Server can send the entire > ServerHello to > Finished flight. > > In QUIC, we are trying to merge those two rounds into one. The problem, > however, is that the ClientHello is one packet, and > ServerHello...Finished can > span multiple packets, meaning that this could be used as an amplification > attack vector since the client's address is not yet authenticated at > this point. > In order to address this, the server has to limit the number of packets > it sends > during the first flight (i.e. ServerHello...Finished flight). Since > certificates make up the majority of data in that flight, making them > smaller > can push them under the limit and save a round-trip. > > Cheers, > Victor. > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
