On Mon, Dec 05, 2016 at 06:13:56PM -0500, Victor Vasiliev wrote:
> This looks promising! I am currently working on figuring out a better
> pre-shared dictionary (based on CT logs analysis) so I don't have that
> much code for the actual TLS parts.
What is the likelihood that a dictionary that is
On 11/29/16 at 5:28 AM, rs...@akamai.com (Salz, Rich) wrote:
Sure, here's my compressed cert. Ignore the fact that it's named "42.zip" --
see https://en.wikipedia.org/wiki/Zip_bomb
The risks of uncompressing data sent from a counterparty who has not yet been
authenticated, do not outweigh the
Sure, here's my compressed cert. Ignore the fact that it's named "42.zip" --
see https://en.wikipedia.org/wiki/Zip_bomb
The risks of uncompressing data sent from a counterparty who has not yet been
authenticated, do not outweigh the gains.
/r$
--
Senior Architect, Akamai Technologies
On Tue, Nov 29, 2016 at 02:05:21PM +0100, Nikos Mavrogiannopoulos wrote:
> Well, PKIX/X.509 parsing seems to be order of magnitude more complex
> than compression :)
I have implemented both at times, so I can confirm that X.509 parsing is
a bit more complex than decompression (with Deflate). The _
On Tue, 2016-11-29 at 13:56 +0100, Hubert Kario wrote:
> > Given that certificates usually take up most of the bytes exchanged
> > during a
> > full handshake it seems this could be useful, but I don't know if
> > in
> > practice the benefits are worth the added complexity. Thoughts?
>
> Decompre
On Sunday, 27 November 2016 01:54:37 CET Alessandro Ghedini wrote:
> Hello,
>
> not sure if this has been discussed before (apologies if it has).
>
> QUIC mandates that certificate chains be gzip compressed in order to reduce
> the amount of bytes transmitted during full handshake.
>
> The QUIC
On Sun, 2016-11-27 at 15:13 +, Alessandro Ghedini wrote:
> On Sat, Nov 26, 2016 at 11:42:20PM -0500, Victor Vasiliev wrote:
> > I am currently trying to figure out how much of QUIC certificate
> > compression can be adapted to work with TLS. I will submit a draft
> > as soon
> > as I have a wo
On Sun, Nov 27, 2016 at 03:13:04PM +, Alessandro Ghedini wrote:
> On Sat, Nov 26, 2016 at 11:42:20PM -0500, Victor Vasiliev wrote:
> > I am currently trying to figure out how much of QUIC certificate
> > compression can be adapted to work with TLS. I will submit a draft as soon
> > as I have
On Sat, Nov 26, 2016 at 11:42:20PM -0500, Victor Vasiliev wrote:
> I am currently trying to figure out how much of QUIC certificate
> compression can be adapted to work with TLS. I will submit a draft as soon
> as I have a working prototype.
FWIW I too have started working on a prototype for gzip
TLS already contains a certificate caching mechanism (
https://tools.ietf.org/html/rfc7924).
A more general scheme looks like it ought to perform better against new
sites, though I've
also heard some questions about whether the additional complexity tradeoff
is worth it.
If someone wanted to write
Hello,
not sure if this has been discussed before (apologies if it has).
QUIC mandates that certificate chains be gzip compressed in order to reduce the
amount of bytes transmitted during full handshake.
The QUIC crypto document says:
Any remaining certificates are gzip compressed with a pre-
11 matches
Mail list logo
