IETF Logo Mail Archive

[TLS] Certificate compression (a la QUIC) for TLS 1.3

Alessandro Ghedini <alessandro@ghedini.me> Sun, 27 November 2016 01:54 UTC

Return-Path: <alessandro@ghedini.me>
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 434BD1294B2 for <tls@ietfa.amsl.com>; Sat, 26 Nov 2016 17:54:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ghedini.me
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 ZFOyzQ6yp0t2 for <tls@ietfa.amsl.com>; Sat, 26 Nov 2016 17:54:41 -0800 (PST)
Received: from marceline.ghedini.me (marceline.ghedini.me [151.236.26.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E61129420 for <tls@ietf.org>; Sat, 26 Nov 2016 17:54:41 -0800 (PST)
Received: from localhost (82-69-45-54.dsl.in-addr.zen.co.uk [82.69.45.54]) by marceline.ghedini.me (Postfix) with ESMTPSA id 38D22230B8 for <tls@ietf.org>; Sun, 27 Nov 2016 01:54:39 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ghedini.me; s=mail; t=1480211679; bh=Cqmo7Bf/CmiYRcFvdNV8SLHP15mvtatbB110POo2Lb0=; h=Date:From:To:Subject:From; b=Rv1kGPKqJheVsSuZWZBE0LRaDS1Pn7KqDJPcvrnlatPM+YsFobq7+8REhvwbUdq5T WIgtjjxh/xJ0gRRG2hJD07YtyU9KvHNlFyypZiJJKeZ5YiFKkLHOZjaCfY3M4KORfP Qar4OZquiYbXtAbtEIVw47rIvhWNQW2T2ekW3kJE=
Date: Sun, 27 Nov 2016 01:54:37 +0000
From: Alessandro Ghedini <alessandro@ghedini.me>
To: tls@ietf.org
Message-ID: <20161127015437.kfcwpemeppg3yw7h@pinky.local>
Mail-Followup-To: tls@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: NeoMutt/20161104 (1.7.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/S_fAzk3TPBSHohZxcd0zOAW8COw>
Subject: [TLS] Certificate compression (a la QUIC) for TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 27 Nov 2016 01:54:43 -0000

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-shared dictionary
  that consists of the certificates specified by either of the first two
  methods, and a block of common strings from certificates taken from the
  Alexa top 5000.

https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit#heading=h.fgd4sj5avil0

Has anyone though about including something like that in TLS 1.3?

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?

Cheers

v2.28.0 | Report a Bug | By Email | System Status