Re: [TLS] [Last-Call] Secdir last call review of draft-ietf-tls-certificate-compression-07

Christian Huitema <huitema@huitema.net> Thu, 05 December 2019 21:41 UTC

Return-Path: <huitema@huitema.net>
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 1AEF5120220 for <tls@ietfa.amsl.com>; Thu, 5 Dec 2019 13:41:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 1NxhKQz7ipO6 for <tls@ietfa.amsl.com>; Thu, 5 Dec 2019 13:41:51 -0800 (PST)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA36120867 for <tls@ietf.org>; Thu, 5 Dec 2019 13:41:50 -0800 (PST)
Received: from xse21.mail2web.com ([66.113.196.21] helo=xse.mail2web.com) by mx66.antispamcloud.com with esmtp (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1icysc-0006Jc-It for tls@ietf.org; Thu, 05 Dec 2019 22:41:48 +0100
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 47TTgr0Jkpz1tPr for <tls@ietf.org>; Thu, 5 Dec 2019 13:41:44 -0800 (PST)
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1icysZ-0005O1-TX for tls@ietf.org; Thu, 05 Dec 2019 13:41:43 -0800
Received: (qmail 20224 invoked from network); 5 Dec 2019 21:41:43 -0000
Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <secdir@ietf.org>; 5 Dec 2019 21:41:43 -0000
To: Alessandro Ghedini <alessandro@ghedini.me>
Cc: last-call@ietf.org, draft-ietf-tls-certificate-compression.all@ietf.org, tls@ietf.org, secdir@ietf.org
References: <157498929764.5575.7815291384505057169@ietfa.amsl.com> <20191205164212.GB12839@sokka.flat11.house>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <1740c80a-498f-e706-5622-82d8115cf773@huitema.net>
Date: Fri, 6 Dec 2019 05:41:41 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <20191205164212.GB12839@sokka.flat11.house>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.196.21
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.21/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.21/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0fKZ8wcD78QFAaYhvfMzLIKpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4ZiU+WAv3O8Su+j08Sej1iFgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+eXohGLM8tFKoQ6vM7cAlL2mdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfDtw+Ut ziY+nbU7qa50sEXj8hEv6ylbrSataIASdByf+qyWDcKgIew/Pqmv8CiR0A+Ffy7fEg460Hn2xYnW avStyzAiWbbj13U46jbWFIz21cHX/YzWyFk7762whX3QQ+5uhkPm88V7ziklAaTl19sU919xeAvO xjeQEcL5lNmXdLn4jABaJqtNDIuGYj2WGeveXgFMyx0sD4hRS2uyMFprER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnKW/tiYHEZti Qrr+6ZrIG1ZIkTy17ZAQacqCFwSs+WhjxvH8+JPMngXom5w3xXAoi3eueQZINNaNebrXzVQ+VIMk 6Q9V9YO5wBS5yaTKclLkqt3efQtwMZ/Qk+syj1/xbxg66gs5OuzYxJgw5atIxePaw4mGPOB1lCDk b7ANR1sP2yV1bTpbC+aqtbvkBWfMoNQ84QG89JN6MvpNdzLqW7o5K9HfWgh6ZcxrIvtE/drAHHAS JNUmoOHSoqgqxfHmWfZIwxxhwvMcWh0MGcvUtQj262mS97p/5Wms4KQevObv1vEjHyvS2QZiR+AZ YvfxEvZFKu+ZM2mB1CpThxyaBpbeNHk15VolAGHS5rCXQKDyCQUljhSWDhWh87HBSLhNUo4qiB0X MVQG2R7iUfOzATaF5R3hQJk8CwyURYKQ0Ye0iR3bHfnMCIEU+nrglojKwJanfcoq9IsR6l/OZb9V MEM=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lF5avxm96b_UhZ7aT03OZ6ubaLU>
Subject: Re: [TLS] [Last-Call] Secdir last call review of draft-ietf-tls-certificate-compression-07
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 05 Dec 2019 21:41:55 -0000

On 12/6/2019 12:42 AM, Alessandro Ghedini wrote:
> On Thu, Nov 28, 2019 at 05:01:37PM -0800, Christian Huitema via Datatracker wrote:
>> Reviewer: Christian Huitema
>> Review result: Has Issues
>>
>> I have reviewed draft-ietf-tls-certificate-compression-07 as part of the
>> security directorate's ongoing effort to review all IETF documents being
>> processed by the IESG. These comments were written primarily for the benefit of
>> the security area directors. Document editors and WG chairs should treat these
>> comments just like any other last call comments.
> Thank you for the review!
>
>> Draft-ietf-tls-certificate-compression-07 defines two new TLS extensions to
>> negotiate and then apply compression of the Certificate message. The draft is
>> clear and well written, and the extensions are already widely deployed. I would
>> like to say "ready", but I have to say "almost".
>>
>> This document is almost ready, except for one nit and one issue.
>>
>> First, one nit. The draft references the "Certificate message", but there is no
>> formal reference section 4.4.2 of RFC8446. Please add that, maybe at the
>> beginning of section 4. It may seem obvious to members of the TLS WG, but
>> uninformed readers will appreciate.
> Makes sense. I created https://github.com/tlswg/certificate-compression/pull/30
> to address this.
Thanks.
>
>> Second, my actual concern. Compression may leak information, because different
>> certificate chains will compress differently. The authors mention that an
>> attacker will not be able to inject data in the certificate chain, and thus
>> that attacks of the CRIME variety are unlikely. That's correct, but that's not
>> the entire story.
>>
>> TLS 1.3 will encrypt the compressed certificate message but the length of that
>> message could be deduced from the length of the server's encrypted message.
>> Attackers might be able to derive from that length the identity of the server,
>> even if the SNI is encrypted.
>>
>> One could say that in the absence of compression the length of the certificate
>> chain is also available. Indeed, the problem is flagged in
>> draft-ietf-tls-esni-05, which states in section 5.3 that "it (the server)
>> SHOULD pad the Certificate message, via padding at the record layer, such that
>> its length equals the size of the largest possible Certificate (message)
>> covered by the same ESNI key."
>>
>> Certificate compression introduces a level of complexity here. If only some
>> servers in the anonymity set support compression, attackers can work with a
>> smaller anonymity subset. If all attackers support compression, the padding
>> should try to match the largest Compressed Certificate.
>>
>> It might be good to discuss this issue in the security consideration section.
> I agree tha this is worth discussing, but it seems like it belongs in the ESNI
> draft itself, so implementers of ESNI will be more likely to take compression
> into consideration. That is, we can expand the section you quoted to also
> explicitly mention certificate compression. What do you think? I can look into
> proposing a PR for this.

I agree with you that the bulk of the work belongs in the ESNI draft.
However, it would be nice to have a short reminder of the issue in the
security section of the compression draft. Something like:

Although the Certificate extension is encrypted in TLS 1.3, third
parties can deduce some information about the certificate from the
length of the handshake messages. Compression does not prevent this
issue, as different certificate chains will compress to different
lengths. When privacy is desired, implementers need to consider
appropriate padding strategies. Discussion of these padding strategies
is out of scope for this document.

-- Christian Huitema