Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt

[Victor Vasiliev]

Thank you for your comments!

I've opened a PR to address them:
https://github.com/tlswg/certificate-compression/pull/25

On Sat, Mar 30, 2019 at 2:26 AM John Mattsson 
wrote:

> Two short comments:
>
> -   Would be good to mention that the document does not specify any
> preset dictionaries.
>
> -   Would be good to mention the reason to have the uncompressed
> length. Reading the document I had the same thought that EKR earlier
> expressed on the list: that it was some sort of not so good sanity check.
>
> Cheers,
> John
>
>
>
>
> ___
> 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

Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt

[John Mattsson]

Two short comments:

-   Would be good to mention that the document does not specify any preset 
dictionaries.

-   Would be good to mention the reason to have the uncompressed length. 
Reading the document I had the same thought that EKR earlier expressed on the 
list: that it was some sort of not so good sanity check.

Cheers,
John




___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt

[David Benjamin]

On Tue, Mar 26, 2019 at 6:21 PM Sniffen, Brian  wrote:

> Brotli has a dictionary built into the algorithm. I believe that is indeed
> being used, as it's a part of Brotli. I think the earlier email was saying
> no external certificate-specific dictionary used.
>
>
> Brotli 1.03 and 1.05 each changed the standard dictionary—didn’t they?
> Perhaps I am misreading https://github.com/google/brotli/releases , but
> *even if* the Brotli maintainers are careful, I expect many less careful
> entities to version their compression schemes internally, without updating
> the codepoint.
>

I'm not personally familiar with Brotli's history, but looking through that
link, no I don't believe they changed the standard dictionary. The standard
dictionary is fixed in RFC 7932
. So is the rest of the
decoding algorithm .
Looking through the commits, 1.0.5
 is just talking
about a tool to extract the dictionary from the RFC

.. 1.0.3  appears
to be talking about adding a separate variant

which
is not what the code point in the spec refers to. The spec says codepoint
brotli(2) corresponds to the algorithm defined RFC 7932. If you use another
algorithm, even a related one, it is not brotli(2). Maybe it's
large_window_brotli(123) or brotli(2) plus a separate large_window(456)
extension, but that will be reflected in the transcript.

Even without an RFC, not making wire-incompatible changes to a
serialization format is a rather fundamental requirement. Your decoding
needs to match, or you have not implemented the same thing and will not
interop. The spec can go call that out I suppose, but this is usually
considered redundant.

Compression is just a serialization format that attempts to use fewer bytes
for hopefully likely inputs (and thus more bytes for other, hopefully
unlikely, inputs). Maybe it is family of formats parameterized by a
dictionary, but then someone needs to pick an instantiation. Individual
instantiations are still serialization formats, with the usual expected
rules. Different instantiations will not interop or the dictionary didn't
do anything.

> I don't think "no information flow from the algorithm" is particularly
> well-defined. The output of course takes information flow from the
> algorithm as the algorithm is being run. One could replace Brotli's
> dictionary from an array lookups to a series of ifs, etc., without changing
> the function.
>
> The transcript encoding must be injective, but we inherently have that
> requirement: the receiver needs to decompress it! The transcript includes
> all inputs to the receiver, notably the compression algorithm code point.
>
>
> No, the time of the transaction is a silent input.  I’m worried about
> extremely persistent adversaries, including those who can update some of
> the involved software in apparently-innocent ways.
>

(Some aspects of time actually are part of the transcript by way of the
random values used for freshness.)

If your adversary can change your software, I don't think this is the part
you need to worry about. :-P

But, yeah, if you make wire-incompatible changes to your implementation
over time and introduce ambiguity, the transcript may not work as intended.
It will also presumably fail to interop. This equally true for code points
and length prefixes as compression formats.

David


> -Brian
>
> Were Brotli's static dictionary changed, it would no longer be Brotli. It
> would perhaps be Brotli2 and would want a separate codepoint. To that end,
> I think the discussion on hash table lookups similarly forgot this
> decompressibility requirement. Let's define my_fancy_algorithm to be:
>
> func compress(input) {
>if input == some_particular_cert {
>   return "0x00"
>   }
>   return "0x01" + input
> }
>
> This is silly, but still fine because the codepoint for my_fancy_algorithm
> is in the transcript. It would even be fine if my_fancy_algorithm relied on
> a separately-negotiated dictionary extension. The sender inherently must
> unambiguously communicate the dictionary name. That ends up in the
> transcript. (This is the same logic behind other uses of the handshake
> transcript. Blindly stuffing the handshake bytes into the transcript lets
> us align functional and security requirements.)
>
> David
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt

[Sniffen, Brian]

Brotli has a dictionary built into the algorithm. I believe that is indeed 
being used, as it's a part of Brotli. I think the earlier email was saying no 
external certificate-specific dictionary used.

Brotli 1.03 and 1.05 each changed the standard dictionary—didn’t they?  Perhaps 
I am misreading https://github.com/google/brotli/releases , but *even if* the 
Brotli maintainers are careful, I expect many less careful entities to version 
their compression schemes internally, without updating the codepoint.

I don't think "no information flow from the algorithm" is particularly 
well-defined. The output of course takes information flow from the algorithm as 
the algorithm is being run. One could replace Brotli's dictionary from an array 
lookups to a series of ifs, etc., without changing the function.

The transcript encoding must be injective, but we inherently have that 
requirement: the receiver needs to decompress it! The transcript includes all 
inputs to the receiver, notably the compression algorithm code point.

No, the time of the transaction is a silent input.  I’m worried about extremely 
persistent adversaries, including those who can update some of the involved 
software in apparently-innocent ways.

-Brian

Were Brotli's static dictionary changed, it would no longer be Brotli. It would 
perhaps be Brotli2 and would want a separate codepoint. To that end, I think 
the discussion on hash table lookups similarly forgot this decompressibility 
requirement. Let's define my_fancy_algorithm to be:

func compress(input) {
   if input == some_particular_cert {
  return "0x00"
  }
  return "0x01" + input
}

This is silly, but still fine because the codepoint for my_fancy_algorithm is 
in the transcript. It would even be fine if my_fancy_algorithm relied on a 
separately-negotiated dictionary extension. The sender inherently must 
unambiguously communicate the dictionary name. That ends up in the transcript. 
(This is the same logic behind other uses of the handshake transcript. Blindly 
stuffing the handshake bytes into the transcript lets us align functional and 
security requirements.)

David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt

[David Benjamin]

On Tue, Mar 26, 2019 at 5:07 PM Sniffen, Brian  wrote:

> >> WG - I’d like to echo Alessandro request for reviews.   If this
> outstanding WG item is not resolved before IETF103 we will discuss the
> outstanding issue there, and barring any other major issues we are planning
> to WGLC the draft after IETF103.
> >>
> >> One question: There was some discussion earlier about dictionaries.
> Are dictionaries being used in the current deployments?
> >
> > No, neither Chrome nor Cloudflare are using dictionaries. Something I
> forgot
> > to mention in my previous email is that the numbers are for plain brotli
> > compression, so without dictionary.
>
> Just to check: is this still true for the excellent numbers we saw today?
> Surely it’s only the text-like parts of the certificate that are
> compressed.  As EKR mentioned, presumably a bunch of the savings is from
> compressing the Subject of one cert against the Issuer of another.  Perhaps
> there’s some ASN.1 framing too?
>
> If the Brotli dictionary were there, I’d expect to see compression of
> “Massachusetts” and “Czechia.”  But versioning of that dictionary seems
> dangerous for the same reasons we talked about the hash table lookups being
> dangerous.  Is there a space for a requirement that the decompression
> function contain no information flow from the algorithm, so that all bits
> in the output were present somewhere in the compressed input?
>

Brotli has a dictionary built into the algorithm. I believe that is indeed
being used, as it's a part of Brotli. I think the earlier email was saying
no external certificate-specific dictionary used.

I don't think "no information flow from the algorithm" is particularly
well-defined. The output of course takes information flow from the
algorithm as the algorithm is being run. One could replace Brotli's
dictionary from an array lookups to a series of ifs, etc., without changing
the function.

The transcript encoding must be injective, but we inherently have that
requirement: the receiver needs to decompress it! The transcript includes
all inputs to the receiver, notably the compression algorithm code point.
Were Brotli's static dictionary changed, it would no longer be Brotli. It
would perhaps be Brotli2 and would want a separate codepoint. To that end,
I think the discussion on hash table lookups similarly forgot this
decompressibility requirement. Let's define my_fancy_algorithm to be:

func compress(input) {
   if input == some_particular_cert {
  return "0x00"
  }
  return "0x01" + input
}

This is silly, but still fine because the codepoint for my_fancy_algorithm
is in the transcript. It would even be fine if my_fancy_algorithm relied on
a separately-negotiated dictionary extension. The sender inherently must
unambiguously communicate the dictionary name. That ends up in the
transcript. (This is the same logic behind other uses of the handshake
transcript. Blindly stuffing the handshake bytes into the transcript lets
us align functional and security requirements.)

David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt

[Sniffen, Brian]

>> WG - I’d like to echo Alessandro request for reviews.   If this outstanding 
>> WG item is not resolved before IETF103 we will discuss the outstanding issue 
>> there, and barring any other major issues we are planning to WGLC the draft 
>> after IETF103.
>> 
>> One question: There was some discussion earlier about dictionaries.  Are 
>> dictionaries being used in the current deployments?
> 
> No, neither Chrome nor Cloudflare are using dictionaries. Something I forgot
> to mention in my previous email is that the numbers are for plain brotli
> compression, so without dictionary.

Just to check: is this still true for the excellent numbers we saw today?  
Surely it’s only the text-like parts of the certificate that are compressed.  
As EKR mentioned, presumably a bunch of the savings is from compressing the 
Subject of one cert against the Issuer of another.  Perhaps there’s some ASN.1 
framing too?

If the Brotli dictionary were there, I’d expect to see compression of 
“Massachusetts” and “Czechia.”  But versioning of that dictionary seems 
dangerous for the same reasons we talked about the hash table lookups being 
dangerous.  Is there a space for a requirement that the decompression function 
contain no information flow from the algorithm, so that all bits in the output 
were present somewhere in the compressed input?

-Brian
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt

[Alessandro Ghedini]

On Wed, Oct 03, 2018 at 01:15:22PM -0400, Sean Turner wrote:
> 
> 
> > On Oct 3, 2018, at 08:36, Alessandro Ghedini  wrote:
> > 
> > On Wed, Oct 03, 2018 at 05:29:33AM -0700, internet-dra...@ietf.org wrote:
> >> 
> >> A New Internet-Draft is available from the on-line Internet-Drafts 
> >> directories.
> >> This draft is a work item of the Transport Layer Security WG of the IETF.
> >> 
> >>Title   : TLS Certificate Compression
> >>Authors : Alessandro Ghedini
> >>  Victor Vasiliev
> >>Filename: draft-ietf-tls-certificate-compression-04.txt
> >>Pages   : 7
> >>Date: 2018-10-03
> >> 
> >> Abstract:
> >>   In TLS handshakes, certificate chains often take up the majority of
> >>   the bytes transmitted.
> >> 
> >>   This document describes how certificate chains can be compressed to
> >>   reduce the amount of data transmitted and avoid some round trips.
> >> 
> >> 
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/
> >> 
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-04
> >> https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-04
> >> 
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-04
> > 
> > This is just a tiny update with a few small fixes and the addition of the
> > early code points assigned by IANA.
> > 
> > In other news, Chrome landed support for certificate compression in canary
> > back in July, and Cloudflare deployed support on its edge servers a few
> > weeks ago.
> > 
> > The data we've seen on the Cloudflare side looks quite promising so far,
> > although I haven't had the time to do a full analysis yet. We are seeing
> > reductions in certificates sizes between 1.5-2 KB for both ECDSA and RSA
> > (meaning a full QUIC packet if not more), with average compressed size
> > hovering around 2.1-2.4 KB for ECDSA and 2.5-3.5 KB for RSA.
> > 
> > The only remaining open issue is the potential attack illustrated by Subodh
> > a few months ago 
> > https://www.ietf.org/mail-archive/web/tls/current/msg25851.html
> > 
> >> From the reaction on that mailing list discussion, and from talking to 
> >> people
> > at the last IETF, it seems to me that the attack doesn't appear to worry 
> > people
> > much and that there isn't much interest in fixing it. Though I thought I'd
> > mention it again to see if people have anything to add to it, and see if we
> > can agree on whether we should do anything about it.
> > 
> > Other than that it looks like the draft is in a pretty good shape at this 
> > point,
> > so it'd be nice to have some additional review, and then see if it can 
> > proceed
> > to the next step (which I think would be WGLC).
> 
> Alessandro - thanks for this update.
> 
> WG - I’d like to echo Alessandro request for reviews.   If this outstanding 
> WG item is not resolved before IETF103 we will discuss the outstanding issue 
> there, and barring any other major issues we are planning to WGLC the draft 
> after IETF103.
> 
> One question: There was some discussion earlier about dictionaries.  Are 
> dictionaries being used in the current deployments?

No, neither Chrome nor Cloudflare are using dictionaries. Something I forgot
to mention in my previous email is that the numbers are for plain brotli
compression, so without dictionary.

Cheers

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt

[Sean Turner]

> On Oct 3, 2018, at 08:36, Alessandro Ghedini  wrote:
> 
> On Wed, Oct 03, 2018 at 05:29:33AM -0700, internet-dra...@ietf.org wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Transport Layer Security WG of the IETF.
>> 
>>Title   : TLS Certificate Compression
>>Authors : Alessandro Ghedini
>>  Victor Vasiliev
>>  Filename: draft-ietf-tls-certificate-compression-04.txt
>>  Pages   : 7
>>  Date: 2018-10-03
>> 
>> Abstract:
>>   In TLS handshakes, certificate chains often take up the majority of
>>   the bytes transmitted.
>> 
>>   This document describes how certificate chains can be compressed to
>>   reduce the amount of data transmitted and avoid some round trips.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-04
>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-04
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-04
> 
> This is just a tiny update with a few small fixes and the addition of the
> early code points assigned by IANA.
> 
> In other news, Chrome landed support for certificate compression in canary
> back in July, and Cloudflare deployed support on its edge servers a few
> weeks ago.
> 
> The data we've seen on the Cloudflare side looks quite promising so far,
> although I haven't had the time to do a full analysis yet. We are seeing
> reductions in certificates sizes between 1.5-2 KB for both ECDSA and RSA
> (meaning a full QUIC packet if not more), with average compressed size
> hovering around 2.1-2.4 KB for ECDSA and 2.5-3.5 KB for RSA.
> 
> The only remaining open issue is the potential attack illustrated by Subodh
> a few months ago 
> https://www.ietf.org/mail-archive/web/tls/current/msg25851.html
> 
>> From the reaction on that mailing list discussion, and from talking to people
> at the last IETF, it seems to me that the attack doesn't appear to worry 
> people
> much and that there isn't much interest in fixing it. Though I thought I'd
> mention it again to see if people have anything to add to it, and see if we
> can agree on whether we should do anything about it.
> 
> Other than that it looks like the draft is in a pretty good shape at this 
> point,
> so it'd be nice to have some additional review, and then see if it can proceed
> to the next step (which I think would be WGLC).

Alessandro - thanks for this update.

WG - I’d like to echo Alessandro request for reviews.   If this outstanding WG 
item is not resolved before IETF103 we will discuss the outstanding issue 
there, and barring any other major issues we are planning to WGLC the draft 
after IETF103.

One question: There was some discussion earlier about dictionaries.  Are 
dictionaries being used in the current deployments?

spt
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt

[Alessandro Ghedini]

On Wed, Oct 03, 2018 at 05:29:33AM -0700, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
> 
> Title   : TLS Certificate Compression
> Authors : Alessandro Ghedini
>   Victor Vasiliev
>   Filename: draft-ietf-tls-certificate-compression-04.txt
>   Pages   : 7
>   Date: 2018-10-03
> 
> Abstract:
>In TLS handshakes, certificate chains often take up the majority of
>the bytes transmitted.
> 
>This document describes how certificate chains can be compressed to
>reduce the amount of data transmitted and avoid some round trips.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-04
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-04

This is just a tiny update with a few small fixes and the addition of the
early code points assigned by IANA.

In other news, Chrome landed support for certificate compression in canary
back in July, and Cloudflare deployed support on its edge servers a few
weeks ago.

The data we've seen on the Cloudflare side looks quite promising so far,
although I haven't had the time to do a full analysis yet. We are seeing
reductions in certificates sizes between 1.5-2 KB for both ECDSA and RSA
(meaning a full QUIC packet if not more), with average compressed size
hovering around 2.1-2.4 KB for ECDSA and 2.5-3.5 KB for RSA.

The only remaining open issue is the potential attack illustrated by Subodh
a few months ago https://www.ietf.org/mail-archive/web/tls/current/msg25851.html

>From the reaction on that mailing list discussion, and from talking to people
at the last IETF, it seems to me that the attack doesn't appear to worry people
much and that there isn't much interest in fixing it. Though I thought I'd
mention it again to see if people have anything to add to it, and see if we
can agree on whether we should do anything about it.

Other than that it looks like the draft is in a pretty good shape at this point,
so it'd be nice to have some additional review, and then see if it can proceed
to the next step (which I think would be WGLC).

Cheers

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : TLS Certificate Compression
Authors : Alessandro Ghedini
  Victor Vasiliev
Filename: draft-ietf-tls-certificate-compression-04.txt
Pages   : 7
Date: 2018-10-03

Abstract:
   In TLS handshakes, certificate chains often take up the majority of
   the bytes transmitted.

   This document describes how certificate chains can be compressed to
   reduce the amount of data transmitted and avoid some round trips.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-04
https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls