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

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 14 February 2018 15:32 UTC

Return-Path: <ilariliusvaara@welho.com>
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 2C856124C27 for <tls@ietfa.amsl.com>; Wed, 14 Feb 2018 07:32:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 Fz1WUclb7359 for <tls@ietfa.amsl.com>; Wed, 14 Feb 2018 07:32:15 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84931200C1 for <tls@ietf.org>; Wed, 14 Feb 2018 07:32:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id E80C54F83E; Wed, 14 Feb 2018 17:32:12 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id lV6Sep3hg01F; Wed, 14 Feb 2018 17:32:12 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id F086D73; Wed, 14 Feb 2018 17:32:09 +0200 (EET)
Date: Wed, 14 Feb 2018 17:32:09 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Olivier Levillain <olivier.levillain@ssi.gouv.fr>
Cc: tls@ietf.org
Message-ID: <20180214153209.GA14576@LK-Perkele-VII>
References: <151696190108.24397.6150515497869897080@ietfa.amsl.com> <2829c71e-d97a-ccd6-6252-b6b5439e6c70@ssi.gouv.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2829c71e-d97a-ccd6-6252-b6b5439e6c70@ssi.gouv.fr>
User-Agent: Mutt/1.9.3 (2018-01-21)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ROJeMbrPxO0wHjhXyFxlsSwfPCs>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt
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, 14 Feb 2018 15:32:18 -0000

On Wed, Feb 14, 2018 at 10:19:58AM +0100, Olivier Levillain wrote:
> Hi list,
> 
> Le 26/01/2018 à 11:18, internet-drafts@ietf.org a écrit :
> > 
> > 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           : Transport Layer Security (TLS) Certificate Compression
> >         Authors         : Alessandro Ghedini
> >                           Victor Vasiliev
> > 	Filename        : draft-ietf-tls-certificate-compression-02.txt
> > 	Pages           : 7
> > 	Date            : 2018-01-26
> 
> 
> I am sorry I am late in the process of commenting this draft, but I have
> a question about the CompressedCertificate message: why does it contain
> an uncompressed_length field?

To know beforehand how much memory to allocate so one is able to
perform oneshot decompression.
 
> What is the point of this field which can not be trusted? If the idea is
> to give a hint of how long a certificate is, we already know that.

The compression ratio can vary.

> Since the whole goal of this draft is to reduce the size of the message,
> I would strongly suggest this field be removed. It is too much a
> temptation to be considered as a reliable information for shaky
> implementations.

It actaully makes writing solid decompressors easier. At least if the
decompressor API is at least as good as zlib.

If you know the sizes up front, you can do the decompression in one shot,
and check that the availables are zero afterwards. Compare this with messing
with variable-sized buffers. The chances of mistake are greatly increased if
one has to resize buffers.


-Ilari