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

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 11 December 2017 06:09 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 9958F12702E for <tls@ietfa.amsl.com>; Sun, 10 Dec 2017 22:09:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 5sKxJ5cOtc0G for <tls@ietfa.amsl.com>; Sun, 10 Dec 2017 22:09:40 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797DF1241FC for <tls@ietf.org>; Sun, 10 Dec 2017 22:09:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id E8956B51E5; Mon, 11 Dec 2017 08:09:37 +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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id a2-PThQ4oqZM; Mon, 11 Dec 2017 08:09:37 +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 892D072; Mon, 11 Dec 2017 08:09:35 +0200 (EET)
Date: Mon, 11 Dec 2017 08:09:35 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Message-ID: <20171211060935.GA4599@LK-Perkele-VII>
References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171209123023.GA8296@pinky> <CABkgnnUdKJZ++dV_Vc1jGFpieAvAqVq=H8+1uB_NkNeSgLys-Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABkgnnUdKJZ++dV_Vc1jGFpieAvAqVq=H8+1uB_NkNeSgLys-Q@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ImqIEXcWMUKz1BVhKxAlnrxynak>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.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: Mon, 11 Dec 2017 06:09:42 -0000

On Mon, Dec 11, 2017 at 09:59:56AM +1100, Martin Thomson wrote:
> A codepoint might be premature just yet.
> 
> The idea of using a new handshake message type is to allow someone to
> choose between compressing and not.  But consider the case where both
> client and server support non-intersecting sets.  This negotiation
> would cause failure, but that would be unnecessary.

New handshake message type is pretty much necressary if one wants to
also compress client certificates. Client does not have answer block
outside certificate message, and trying to use that would lead into
chicken and egg problem.

And on supporting algorithms, the main problem is decompressing.
There are very simple trivial "compression" algorithms for both
Zlib and Brotli. And then there are pre-canned responses.

> You could allow the server to advertise multiple (as the current
> format allows), but in that case, when the server certificate arrives
> and is compressed, the client can't know which compression method was
> used without trialing each.  Similarly, when the client certificate
> arrives, the server can't know which compression method was used
> either.

Guessing here seems extremely bad idea.

In general, in security protocols, you never want to guess what the
other end intended. Trying to guess meaning is recipe for security
problems.

> I think that the best solution to that problem is to include the
> compression scheme in the Certificate message.  It also suggests (to
> me at least) that modifying Certificate rather than defining a
> CompressedCertificate makes sense, though that might not fit with the
> idea that you transform CompressedCertificate into Certificate before
> putting it in the transcript.

Transforming messages before putting them in transcript? That sounds
like recipe for some very nasty implementation headaches.

AFAIK, nothing else in TLS does this. TLS 1.3 has reset hash and inject
synthetic message, but that is a lot easier than actual message
transformation.

> Or, you could trim the list on the server side to a single value, but
> then you have to deal with TLS 1.3 CertificateRequest more explicitly,
> which is currently not at all addressed.  In that spirit, I would also
> suggest that you describe what happens to a TLS 1.3 Certificate
> message that contains extensions (the entire thing is wrapped up as a
> whole, I assume).

Yes, that is what I get from the document.


-Ilari