Hi Hannes.
Cached-Info is useful, but it can only "compress" if the client has
previously seen and cached the server's certificate.
AIUI, the purpose of draft-ghedini-tls-certificate-compression is to
enable compression even in cases where the client hasn't yet seen the
server's certificate.
On 07/03/17 08:14, Hannes Tschofenig wrote:
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.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
