Re: [TLS] Asking for certificate authentication when doing 0-RTT

Kyle Nekritz <knekritz@fb.com> Wed, 25 May 2016 02:06 UTC

Return-Path: <prvs=49534cf4bf=knekritz@fb.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 0E13312D188 for <tls@ietfa.amsl.com>; Tue, 24 May 2016 19:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=eC1nspO3; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=CHVoNy8P
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 gLOdOqsh6Wiy for <tls@ietfa.amsl.com>; Tue, 24 May 2016 19:06:55 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 7ABD112D0F2 for <tls@ietf.org>; Tue, 24 May 2016 19:06:55 -0700 (PDT)
Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u4P25nqP024049; Tue, 24 May 2016 19:06:54 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=vrZk3JhSdkrywUzdvW1Kfrqr/m3lvsVb6S7lNyjWFzs=; b=eC1nspO3L/Y2TnnsYa7y+ycWfda+5uU9ciQmB2yixGMGT783LuL0kjV/oMONbgpaUaih CFnIB84wHmipMyVvuYkMkQtxAvGFCD8xVkir6rOO21DaFvpfj/Gqhw7OonUTyTVNrAsI HgFj+vi4XSFzbc26NA2p3CrdmSLrYq8DgQc=
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 234ywg8t5p-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 May 2016 19:06:54 -0700
Received: from na01-bn1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.32) with Microsoft SMTP Server (TLS) id 14.3.294.0; Tue, 24 May 2016 22:06:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Qt7XMJ5s28bfysXheLzM9+f5ECcFmOEnEjqyLGID+74=; b=CHVoNy8P9BXioF1iObB8Uzbqd+0X6XxY5oPGmXrZlpKMZ8CNSal3Mp+zmSveJuFov7e/OVXMvOsJTHoTPezBv6Zl1aJzlSjRuJXmiVDNb7kBN/ni3iDj+dXZ9bPcK9ONoqD+HiSdxCBTeW37nPPKSg9JUOpu/n/H0mERyJZL6+c=
Received: from BLUPR15MB0275.namprd15.prod.outlook.com (10.162.232.26) by BLUPR15MB0273.namprd15.prod.outlook.com (10.162.232.24) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 25 May 2016 02:06:51 +0000
Received: from BLUPR15MB0275.namprd15.prod.outlook.com ([10.162.232.26]) by BLUPR15MB0275.namprd15.prod.outlook.com ([10.162.232.26]) with mapi id 15.01.0497.022; Wed, 25 May 2016 02:06:51 +0000
From: Kyle Nekritz <knekritz@fb.com>
To: Martin Thomson <martin.thomson@gmail.com>, Ilari Liusvaara <ilariliusvaara@welho.com>
Thread-Topic: [TLS] Asking for certificate authentication when doing 0-RTT
Thread-Index: AQHRsQ8Scc6AdnpECkGEG7MzEe33vJ/CPQaAgAZfbgCAAEbxMA==
Date: Wed, 25 May 2016 02:06:51 +0000
Message-ID: <BLUPR15MB02755CE39A33011905E6F056AF400@BLUPR15MB0275.namprd15.prod.outlook.com>
References: <CABkgnnXoNT7BBbbHGBMnb3iNwjj4ZVSNavrKgQFG-hiPGw96Bw@mail.gmail.com> <20160520194115.GA5467@LK-Perkele-V2.elisa-laajakaista.fi> <CABkgnnXuhDfFHniHmRO+hk0pgV0UzNvMcgkq9nyPT+bUZkJ9tA@mail.gmail.com>
In-Reply-To: <CABkgnnXuhDfFHniHmRO+hk0pgV0UzNvMcgkq9nyPT+bUZkJ9tA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=fb.com;
x-originating-ip: [2620:10d:c090:180::1:c37b]
x-ms-office365-filtering-correlation-id: c8da4dd4-f7e5-43c9-f8af-08d384413cbe
x-microsoft-exchange-diagnostics: 1; BLUPR15MB0273; 5:s9JLYh1fSZnrpRKLPXJyjMuCJ/zLnA+8PYeaCUed63G3/wD2lap5kfkKbuK2kUHdulwBzi2Y4wSlgsuC77o6Aq2u5yDq0t2zXa/7Z8huc+w5olIoBMkMah9JseKSaHs6gOuAEyGqBlMoRtvkyG65oA==; 24:B5IXoslnufa0BGCMt22SnIAT6RYqY6GCtsHj4ZZ7+N7uRctXQTcnc3TIKxxvNr2mOtDiG9AIV/KrdgZj4Rx83YP+xytaDhyR7Wrekrem2O4=; 7:0ZU7vp4MVyGbwkn5F5VepOJr8pCc0jqvj8wgllgi82yHfUp1GjT5piZCUmaPSwuvRGr2m/YD1SynYLTwNAQyVpisO1qUpB8ZIbIUFtfVHlZiUOXMmQAQN3lOcC9KGdRtNiQiZFb79H426hsH+AK0fCPvflBFOYKyyYvi9Mp60iIF3WwRpEnMqj+2iGwF6/hJ; 20:Mx8QPADJakzqYGwyCe8q6vHGY6kYjI07Xzifw/O0DK8F0QwIKlG4BusEJM0Jd90P3ZynVUUbWxUHmlYW901khb+TEQwGq2TBG1GbSujFjXKgPtC0ro3+/U1sazAdypy1346CycVkcBmqlWNb3FrLcPPxGgpfeR+0DT8SAAx1seE=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR15MB0273;
x-microsoft-antispam-prvs: <BLUPR15MB02739ED6BE0B5FB9802B083DAF400@BLUPR15MB0273.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BLUPR15MB0273; BCL:0; PCL:0; RULEID:; SRVR:BLUPR15MB0273;
x-forefront-prvs: 09538D3531
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(13464003)(77096005)(1220700001)(189998001)(5003600100002)(586003)(19580405001)(6116002)(19580395003)(99286002)(50986999)(102836003)(76576001)(106116001)(8936002)(81166006)(74316001)(122556002)(92566002)(8676002)(76176999)(5001770100001)(5002640100001)(2906002)(5008740100001)(575784001)(86362001)(3280700002)(11100500001)(2950100001)(5004730100002)(33656002)(54356999)(3660700001)(9686002)(87936001)(2900100001)(10400500002)(15975445007)(4326007)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR15MB0273; H:BLUPR15MB0275.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2016 02:06:51.3135 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR15MB0273
X-OriginatorOrg: fb.com
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-25_01:, , signatures=0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/zhtBXr4hTQRV57uyCBVDacq9-D4>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Asking for certificate authentication when doing 0-RTT
X-BeenThere: tls@ietf.org
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." <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, 25 May 2016 02:06:57 -0000

What is the rationale for restricting a change in certificate? If the server has a new certificate that the client would accept with a full handshake, what threat is added by also accepting that certificate with a PSK handshake?

Requiring the certificate to remain the same will make rollout of a new certificate more challenging (even with longer-lived certificates), particularly on distributed servers where the update is not immediate fleet-wide. It will also add noise to metrics when rolling out a new certificate when ideally you want everything relatively constant (to be confident the new certificate is working properly).

Kyle

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Tuesday, May 24, 2016 5:00 PM
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Asking for certificate authentication when doing 0-RTT

On 20 May 2016 at 12:41, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> On Wed, May 18, 2016 at 10:10:29AM -0400, Martin Thomson wrote:
>> I just posted this:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
>> .org_doc_draft-2Dthomson-2Dtls-2D0rtt-2Dand-2Dcerts_&d=CwICAg&c=5VD0R
>> TtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=cJNWhprXjoJ1zN66VdIpTtqs
>> s54Z2N5U0l61Yj7RL_I&s=hd6AtOpOp_1ULpSo_TRrpuxmTwQKZrjr6oz0Tm0hASs&e=
>>
>> It's fairly self explanatory.  The idea is to create a way to signal 
>> that the client wants the server to re-authenticate itself, even if 
>> it successful in using a pre-shared key.
>
> - How is the capability signaled? New flag bits in session ticket
>   for these ciphersuites?


I just uploaded -01 that corrects this oversight.

I have raised https://github.com/martinthomson/tls-0rtt-and-certs/issues/1
which tracks whether certificates might change.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=cJNWhprXjoJ1zN66VdIpTtqss54Z2N5U0l61Yj7RL_I&s=2divOhlUGndixU6HSAFfmzyMt_Ufkc58GwbPbrg19GM&e=