Re: [TLS] Reminders

Anirudh Ramachandran <> Mon, 11 July 2016 22:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA2C112B03B for <>; Mon, 11 Jul 2016 15:27:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=ey/aoPmR; dkim=pass (1024-bit key) header.b=TKbRbvTT
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zl5ZWg9JumE1 for <>; Mon, 11 Jul 2016 15:27:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C27012B02A for <>; Mon, 11 Jul 2016 15:27:56 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u6BMPL6s021868; Mon, 11 Jul 2016 15:27:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=hre0gDDnzH5esMQr3bHfMYmdMxqLYbmb6591cTCEMTw=; b=ey/aoPmR/PyfvqsY1k1FWcNnd4UiKqO6qaRcIp8xTKddMqWsi0/6MQUPjojRDnXRE8KO KQZY+s1KoPkJM/OQ8kKU1MByCBz2VxpLfZ9X7F9YpwK+ua9st7zgTZUNx17k556yh4x/ V7ke6IwpRAsU5d8VOufjqnmZ7+K0hySetoE=
Received: from ([]) by with ESMTP id 244jaf8rqm-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jul 2016 15:27:55 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 11 Jul 2016 18:27:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hre0gDDnzH5esMQr3bHfMYmdMxqLYbmb6591cTCEMTw=; b=TKbRbvTTsHJssUex81s1wE5g+6bZEfAZl4sayJA+tCc0a4BwhW2WwjgDwT2nTmqrSkL/XR0y5FCDeaBWFWpk8IzScpJKu6cSPi4u84dU2eZsAZ0Ppm2mP81khdnb+NVvcW6BjKvWt/2qR5pWUYAtsq0ZAH3WLX4uDkb78hWF2h4=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.534.14; Mon, 11 Jul 2016 22:27:52 +0000
Received: from ([]) by ([]) with mapi id 15.01.0534.013; Mon, 11 Jul 2016 22:27:52 +0000
From: Anirudh Ramachandran <>
To: "<>" <>
Thread-Topic: [TLS] Reminders
Thread-Index: AQHR28HpJEy/g6oSVkSS1RwlP1cD7KATWg0A
Date: Mon, 11 Jul 2016 22:27:52 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2620:10d:c090:180::1:171e]
x-ms-office365-filtering-correlation-id: 840f9ddd-822b-4174-fdf2-08d3a9da98fc
x-microsoft-exchange-diagnostics: 1; BL2PR15MB1058; 20:4kODzcUsx1ynpuaO9GvUW2e1+mHQ+aVm7+6JYZfBqcOOjgvB1+ouSbgfzZ4zDxMN0nAXEaH8bNEPNDyvLcOPNzWDah6yhPO3+mxUrzh3CT3uWnO5ti7AmPj/20tSyuP/g/IjIgJx6rbCSIut3xHCKGAlF9Kd1nb2XRDWGnoF1Jo=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR15MB1058;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BL2PR15MB1058; BCL:0; PCL:0; RULEID:; SRVR:BL2PR15MB1058;
x-forefront-prvs: 00003DBFE7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(24454002)(199003)(189002)(12213003)(86362001)(11100500001)(106116001)(4326007)(105586002)(82746002)(101416001)(16236675004)(106356001)(5002640100001)(76176999)(189998001)(97736004)(122556002)(7736002)(87936001)(50986999)(2900100001)(19625215002)(68736007)(36756003)(54356999)(93886004)(10400500002)(3280700002)(19300405004)(81166006)(8676002)(15975445007)(81156014)(99286002)(19580405001)(77096005)(3660700001)(110136002)(102836003)(6116002)(92566002)(8936002)(586003)(2906002)(2950100001)(19580395003)(7846002)(83716003)(33656002)(3826002)(104396002)(42262002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR15MB1058;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_499E287399F147A9A7B7BCA529A1A3C0fbcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2016 22:27:52.1991 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR15MB1058
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-11_14:, , signatures=0
Archived-At: <>
Subject: Re: [TLS] Reminders
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Jul 2016 22:27:58 -0000

On Mon, Jul 11, 2016 at 9:16 AM, David Benjamin <<>> wrote:

> OpenSSL determines which certificate to use during ClientHello processing, but it has a mode where, if intermediates were not explicitly configured and only a leaf, it path-builds right before sending the Certificate message. But I don't see any reason why it can't be changed to compute this earlier.

Correct, OpenSSL's late computation of the chain, plus other design decisions (one-state-at-a-time, same buffer for everything, etc) is the reason I proposed the change. Since the draft requires cached-info to be the hash of the serialized chain rather than individual certs, it does require the serialization code to be run outside of the usual state machine codepath, which is also cumbersome.

The MAY instead of MUST makes the server-side implementation almost plug-in - serialization happens as normal and the serialized message is replaced if it matches a cached-info. The client side implementation only slightly more complicated - check first for a length match and then a cached-info match (needed anyway); if either fail, the client treats the message as a normal certificate.

Having another way to indicate this besides length would suffice too, but I'm fine with not changing the draft either if that's what everyone feels.