IETF Logo Mail Archive

Re: [TLS] Review of PR #209

Andrei Popov <Andrei.Popov@microsoft.com> Tue, 15 September 2015 20:18 UTC

Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44771ACDEB for <tls@ietfa.amsl.com>; Tue, 15 Sep 2015 13:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 C-l8P4XGKtwv for <tls@ietfa.amsl.com>; Tue, 15 Sep 2015 13:17:59 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E561ACE73 for <tls@ietf.org>; Tue, 15 Sep 2015 13:17:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uZzTWPojNlIaoYyE0Xl2RzLHU3rMWH/oaLE2zDc8qPo=; b=VQTIxE4MmEIB/vOOVC+rowypn++tQmgg4lF7BoABmD7GtkxvCZa9UeFo/CM81WNoFTKvKhT/ATQnEipODSHysJs1jpNcuZHZhB3G2rb/M1r289izNWWpY4nYQLhtfxTBp1jFgNjVJ/j4tCTFNDSz7wJV70CdKrGwBFJC1IRVaYU=
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.268.17; Tue, 15 Sep 2015 20:17:56 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0268.017; Tue, 15 Sep 2015 20:17:56 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Martin Thomson <martin.thomson@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Review of PR #209
Thread-Index: AQHQxuqZE5b0AgbP4UGzDBeqZzcHy54+TSMg
Date: Tue, 15 Sep 2015 20:17:56 +0000
Message-ID: <BLUPR03MB13962416E8D8AD71CFFE13C08C5C0@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <CABkgnnWtUjH1b3xm_peffNxNpxXE9rudJLJpn1ExNpE7B29AhA@mail.gmail.com>
In-Reply-To: <CABkgnnWtUjH1b3xm_peffNxNpxXE9rudJLJpn1ExNpE7B29AhA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
x-originating-ip: [2001:4898:80e8:2::1d2]
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:1zMeCjEnuQlMeL/QRdADM7lz8u0KAqKzvBTTgb4eWky0QrsqVMcEsfTAt9j5Dj3vtXubL7a2b9Y6Tbr2kmPc0vk1gLVzK4ShDxFplzRbj4bwhx79a/jpPYK/yIYU7+yKPgUmgvpE6MMKkOaGDOtwgA==; 24:K4yJQtnFaGa0a1bZAbKcAcaEmLKXcRCfiQBbQYQ7va6uxmpvZTwW69q5I/FF5AydIc96fc5EL7I1gr/X/KILmcAaav5pVlG0Il1ZU7RbPtc=; 20:JXB1T7hY6QliqEd+9tFjx2jVnhIFwWTaWJFwRurzrrs/vHwJ/SvS0to7dvP/CjfEhpaNmGS2mMzqfhqULLoUxA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395;
x-microsoft-antispam-prvs: <BLUPR03MB1395153843F2E1B48A9D7A9F8C5C0@BLUPR03MB1395.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425019)(601004)(2401001)(520078)(520075)(5005006)(8121501046)(3002001)(61426019)(61427019); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395;
x-forefront-prvs: 070092A9D3
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(51444003)(13464003)(189002)(87936001)(5001830100001)(97736004)(4001540100001)(5001770100001)(76176999)(5007970100001)(5004730100002)(102836002)(10400500002)(68736005)(77096005)(86362001)(81156007)(8990500004)(106116001)(105586002)(10290500002)(62966003)(99286002)(5001920100001)(189998001)(92566002)(46102003)(40100003)(106356001)(64706001)(5002640100001)(122556002)(15975445007)(50986999)(77156002)(74316001)(33656002)(5001860100001)(5001960100002)(5003600100002)(2900100001)(11100500001)(2501003)(76576001)(5005710100001)(19580395003)(101416001)(54356999)(2950100001)(10090500001)(86612001)(107886002)(19580405001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2015 20:17:56.6295 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ZEBJTFXWE4oAL9c_PGQ9-VOsl-c>
Subject: Re: [TLS] Review of PR #209
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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, 15 Sep 2015 20:18:02 -0000

Perhaps we can simplify the protocol by pulling client auth out of the handshake as follows:

1. CertificateRequest, client Certificate, CertificateVerify and NewSessionTicket messages use a new content type distinct from "handshake".
2. The client can send Certificate and CertificateVerify at any time application data is permitted, regardless of whether the server had previously sent CertificateRequest.
3. The server can send CertificateRequest and NewSessionTicket at any time application data is permitted. Alternatively, the server can encapsulate CertificateRequest in an application protocol message.

Encapsulating CertificateRequest in an application protocol message allows the client to determine which specific application request resulted in the need for client auth. The application protocol would of course need to allow this.

As far as I can tell, the above scheme seems to work in both 0-RTT and 1-RTT modes.

We can decide exactly what CertificateVerify would be signing: whether it's the handshake hash or some form of RFC5705 Exported Keying Material (EKM).

Thoughts?

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Saturday, July 25, 2015 8:00 AM
To: tls@ietf.org
Subject: [TLS] Review of PR #209

Andrei proposes two changes in https://github.com/tlswg/tls13-spec/pull/209

The first expands the ways in which a server can identify certificates.  This is fine.  I do wonder whether we can remove CertificateType entirely for TLS 1.3 though (that can be done separately).

The second is worrisome.  I don't like that a handshake message now has two different potential locations that it might appear in.  That seems like a hazard.  I think that we need a new content type for a new message that can be used after the handshake completes.  Then there are two options:
 a) remove CertificateRequest from the handshake entirely and allow the handshake to complete before authenticating (this has a number of hazards that make it probably worse than the duplication it addresses)
 b) use CertificateRequest within the handshake, and the new content type outside of it

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

v2.29.0 | Report a Bug | By Email | System Status