Hi Victor, Do you have any evidence to suggest that this reduces size in any meaningful way? Certificates tend to include both repetitious values (OIDs), and non-repetitious values (keys).
On 7 March 2017 at 09:58, Victor Vasiliev <[email protected]> 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 > _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
