Re: [TLS] Certificate compression draft
Sankalp Bagaria <sankalp@cdac.in> Wed, 05 April 2017 05:36 UTC
Return-Path: <sankalp@cdac.in>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70598129412 for <tls@ietfa.amsl.com>; Tue, 4 Apr 2017 22:36:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NN89h2PWW8IR for <tls@ietfa.amsl.com>; Tue, 4 Apr 2017 22:36:43 -0700 (PDT)
Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E03128BA2 for <tls@ietf.org>; Tue, 4 Apr 2017 22:36:41 -0700 (PDT)
Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id v355aO9D012231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Apr 2017 11:06:29 +0530
Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id v355ZpLQ029649; Wed, 5 Apr 2017 11:05:51 +0530
Received: from webmail.cdac.in (wbms.pune.cdac.in [10.208.1.9]) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id v355ZnJL012159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 5 Apr 2017 11:05:51 +0530
Date: Wed, 05 Apr 2017 11:05:46 +0530
From: Sankalp Bagaria <sankalp@cdac.in>
Reply-To: Sankalp Bagaria <sankalp@cdac.in>
To: tls@ietf.org
Cc: R Balaji <balaji@cdac.in>, "Bagaria, Sankalp" <sankalp.nitt@gmail.com>
Message-ID: <1417765250.1980.1491370546230.JavaMail.open-xchange@webmail.cdac.in>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1979_1883518451.1491370546157"
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v-
X-CDAC-PUNE-MailScanner-ID: v355ZpLQ029649
X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean
X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1)
X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.499, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_05 -0.50, HTML_MESSAGE 0.00, RP_MATCHES_RCVD -0.00, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-1.798, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_50 0.00, HTML_MESSAGE 0.00)
X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information
X-MailScanner-ID: v355aO9D012231
X-CDAC-PUNE-MailScanner-From: sankalp@cdac.in
X-CDAC-MailScanner-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/D3x928PbVTumrS3u6TolBWLEQYQ>
Subject: Re: [TLS] Certificate compression draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Apr 2017 05:36:46 -0000
Hello, How is Certificate Compression advantageous over tls cached-info extension? Only case I can think of is - when the certificate is being sent for the first time, it can be compressed. Since the client doesn't have a copy of the certificate, cached-info can't be used. Are there more cases where compression is useful? Another point that need to be seen is that the time required to compress/ decompress is not more than the savings got in transmitting a compressed certificate (smaller in size than complete certificate). Thanks and Regards, Sankalp Bagaria. On Mon, Mar 6, 2017 at 2:58 PM, Victor Vasiliev < vasilvv@google.com <mailto:vasilvv@google.com> > 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- > <https://datatracker.ietf.org/doc/draft-ghedini-tls-> > certificate - compression / > [ GitHub repo: https://github.com/ghedo/tls-certificate-compression > <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. ------------------------------------------------------------------------------------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. -------------------------------------------------------------------------------------------------------------------------------
- [TLS] Certificate compression draft Victor Vasiliev
- Re: [TLS] Certificate compression draft Martin Thomson
- Re: [TLS] Certificate compression draft Victor Vasiliev
- Re: [TLS] Certificate compression draft Viktor Dukhovni
- Re: [TLS] Certificate compression draft Vlad Krasnov
- Re: [TLS] Certificate compression draft Victor Vasiliev
- Re: [TLS] Certificate compression draft Victor Vasiliev
- Re: [TLS] Certificate compression draft Martin Thomson
- Re: [TLS] Certificate compression draft Vlad Krasnov
- Re: [TLS] Certificate compression draft Ryan Sleevi
- Re: [TLS] Certificate compression draft Viktor Dukhovni
- Re: [TLS] Certificate compression draft Martin Thomson
- Re: [TLS] Certificate compression draft Hannes Tschofenig
- Re: [TLS] Certificate compression draft Rob Stradling
- Re: [TLS] Certificate compression draft Eric Rescorla
- Re: [TLS] Certificate compression draft Victor Vasiliev
- Re: [TLS] Certificate compression draft Sankalp Bagaria
- Re: [TLS] Certificate compression draft Ryan Sleevi
- Re: [TLS] Certificate compression draft Eric Rescorla
- Re: [TLS] Certificate compression draft Benjamin Kaduk
- Re: [TLS] Certificate compression draft David Benjamin
- Re: [TLS] Certificate compression draft Eric Rescorla
- Re: [TLS] Certificate compression draft Eric Rescorla
- Re: [TLS] Certificate compression draft Sankalp Bagaria