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

"Sniffen, Brian" <bsniffen@akamai.com> Tue, 26 March 2019 17:21 UTC

Return-Path: <bsniffen@akamai.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 5B40112074C for <tls@ietfa.amsl.com>; Tue, 26 Mar 2019 10:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level:
X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 9-kOXksav8x3 for <tls@ietfa.amsl.com>; Tue, 26 Mar 2019 10:21:27 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 A02011206EC for <tls@ietf.org>; Tue, 26 Mar 2019 10:21:20 -0700 (PDT)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2QHHX1H008631; Tue, 26 Mar 2019 17:21:19 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=o33H1vWhRa52hLHRb5hSxVziLq0bQ+84Z/Rojucp6ys=; b=aKs3MVfXJjPq6cZJWTlIjVX2WeJjEL8H831laey8Ya0Rhog/z3zrjodOWKdsA7+T4mgk SKU2Ws0xBzclhrypkYTK9u61ycqtrlzCSB/CKEl9d+x/eJ3+/6dOJ1YvWiKlouCmyTyI Y0Cazep645dywdWRu0BXjvcO78CLl5WlMzUFP5YaQTTT10QnyKyb0s+QAyvOG28Z1cqh GYBx+gU6IOuvTRcNDj319US6ZKHRSoWdDF624F41Wutv7EOtnnA15rafg+h7aUoMQBZ6 LQ1r1unBOh+Lh5S6wVz41nVAo1ASGzl4dGH1uFb75T0zmUgf/Whb6Sq+8/VfRI3nwfa5 yg==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2rf3r9bkuf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Mar 2019 17:21:19 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x2QHHNLZ020228; Tue, 26 Mar 2019 13:21:18 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2rdg4vncw5-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 26 Mar 2019 13:21:16 -0400
Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 12:21:01 -0500
Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1473.003; Tue, 26 Mar 2019 12:21:01 -0500
From: "Sniffen, Brian" <bsniffen@akamai.com>
To: David Benjamin <davidben@chromium.org>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt
Thread-Index: AQHUWxTdgLqoGD5KRk2mXCj0gRBTQaUNuF+AgABN2gCAAY5uAIEPkTwjgABhY4D//7Mh6w==
Date: Tue, 26 Mar 2019 17:21:01 +0000
Message-ID: <1F8D6DC4-813D-47D3-810E-6F18662E67A1@akamai.com>
References: <153856977342.9010.10521757586695280@ietfa.amsl.com> <20181003123643.GA5454@mandy.flat11.house> <EC87E55E-A342-40D7-9E09-DB790B04BB9F@sn3rd.com> <20181004170124.GA13528@mandy.flat11.house> <63200ECA-5F92-44A1-970D-E96F90B89EE9@akamai.com>, <CAF8qwaCUVy-V7G4J6SPiSzg8oRurAK6VmtdCy242RuVPL3AGKw@mail.gmail.com>
In-Reply-To: <CAF8qwaCUVy-V7G4J6SPiSzg8oRurAK6VmtdCy242RuVPL3AGKw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_1F8D6DC4813D47D3810E6F18662E67A1akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-26_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903260120
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-26_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903260120
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/z6x4Ka6E0T02wpZh_qjUajnUs5E>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt
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: Tue, 26 Mar 2019 17:21:30 -0000

Brotli has a dictionary built into the algorithm. I believe that is indeed being used, as it's a part of Brotli. I think the earlier email was saying no external certificate-specific dictionary used.

Brotli 1.03 and 1.05 each changed the standard dictionary—didn’t they?  Perhaps I am misreading https://github.com/google/brotli/releases , but *even if* the Brotli maintainers are careful, I expect many less careful entities to version their compression schemes internally, without updating the codepoint.

I don't think "no information flow from the algorithm" is particularly well-defined. The output of course takes information flow from the algorithm as the algorithm is being run. One could replace Brotli's dictionary from an array lookups to a series of ifs, etc., without changing the function.

The transcript encoding must be injective, but we inherently have that requirement: the receiver needs to decompress it! The transcript includes all inputs to the receiver, notably the compression algorithm code point.

No, the time of the transaction is a silent input.  I’m worried about extremely persistent adversaries, including those who can update some of the involved software in apparently-innocent ways.

-Brian

Were Brotli's static dictionary changed, it would no longer be Brotli. It would perhaps be Brotli2 and would want a separate codepoint. To that end, I think the discussion on hash table lookups similarly forgot this decompressibility requirement. Let's define my_fancy_algorithm to be:

func compress(input) {
   if input == some_particular_cert {
      return "0x00"
  }
  return "0x01" + input
}

This is silly, but still fine because the codepoint for my_fancy_algorithm is in the transcript. It would even be fine if my_fancy_algorithm relied on a separately-negotiated dictionary extension. The sender inherently must unambiguously communicate the dictionary name. That ends up in the transcript. (This is the same logic behind other uses of the handshake transcript. Blindly stuffing the handshake bytes into the transcript lets us align functional and security requirements.)

David