Re: [TLS] Certificate compression draft

[Eric Rescorla <[e-mail]>]

This proposal seems like a reasonable idea. One question I had is what the
point of the "uncompressed length" field is:

       struct {
            uint24 uncompressed_length;
            opaque compressed_certificate_message<1..2^24-1>;
       } Certificate;

I initially thought maybe it was a sanity check, but if so it's not a very
good
one. I see that in S 5 you encourage receivers to limit the compressed
length, but having it expressed like this doesn't seem like that useful a
security measure because the attacker gets to choose both the compressed
data and the length. Is the idea just to let the receiver pre-allocate a
buffer
for decompression?


The text says:

   compressed_certificate_message  The compressed body of the
      Certificate message, in the same format as the server would
      normally express it.  The compression algorithm defines how the
      bytes in the compressed_certificate_message are converted into the
      Certificate message.

I assume in this case "body" means "not including the header bytes"? I
guess it's
redundant, but it might be worthwhile being very precise


Also:

   The implementations MUST limit the size of the resulting decompressed
   chain to the specified uncompressed length, and they MUST abort the
   connection if the size exceeds that limit.  Implementations MAY
   impose a lower limit on the chain size in addition to the 16777216
   byte limit imposed by TLS framing, in which case they MUST apply the
   same limit to the uncompressed chain before starting to decompress
   it.

Do you mean "upper" rather than "lower" for limit?

-Ekr





On Mon, Mar 6, 2017 at 2:58 PM, Victor Vasiliev <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>