IETF Logo Mail Archive

Re: [TLS] Review of PR #209

Andrei Popov <Andrei.Popov@microsoft.com> Tue, 04 August 2015 00:21 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 EEE541B2A5D for <tls@ietfa.amsl.com>; Mon, 3 Aug 2015 17:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 k4CZCJupSEHA for <tls@ietfa.amsl.com>; Mon, 3 Aug 2015 17:21:07 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64E11B2A5C for <tls@ietf.org>; Mon, 3 Aug 2015 17:21:06 -0700 (PDT)
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 00:21:02 +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.0225.018; Tue, 4 Aug 2015 00:21:02 +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: AQHQxuqZE5b0AgbP4UGzDBeqZzcHy537BwWQ
Date: Tue, 04 Aug 2015 00:21:02 +0000
Message-ID: <BLUPR03MB139691C8170B9905BA3905168C760@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; BLUPR03MB1396; 5:K4wKqBzWuUSC1rqP/L87mSQhNCvqoWa2Nxdn+e4QB0rwBJijPVhTjWSxYIpjLsqopKmDWof34OszEUvBIl2DI6a8NeaqvZZxC2rbZc073y+hRhm3BXqmyGpuC9CJhr6z0EDi1jf5qginooMFUVE1GQ==; 24:IhTHbalb8NjFo6tC429fMtUNTe+xy3NT85keBC1ohVo6VYPhJvd/8pjd1mXrE41IlKPOC2mW4XR2U4fbr24COY6QnvlMGOBxVPiiPycmWHU=; 20:YKqWSn6DGev1ygpLBqspDSaqonKzirNFzeYpRQFF7xyM9nuLlAcyGfcvKnh8+afsAu49tI6BA4w4f+jPUKJbDg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396;
x-microsoft-antispam-prvs: <BLUPR03MB139682975816BC3E3B98A29A8C760@BLUPR03MB1396.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396;
x-forefront-prvs: 0658BAF71F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(189002)(51444003)(13464003)(92566002)(2950100001)(2900100001)(62966003)(81156007)(122556002)(106116001)(106356001)(105586002)(2501003)(5002640100001)(189998001)(68736005)(77096005)(40100003)(107886002)(4001540100001)(97736004)(5001960100002)(64706001)(5001770100001)(15975445007)(5003600100002)(102836002)(5001830100001)(5001860100001)(19580405001)(77156002)(101416001)(19580395003)(87936001)(10090500001)(33656002)(2656002)(76576001)(99286002)(76176999)(86612001)(74316001)(86362001)(46102003)(50986999)(54356999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; 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)
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: 04 Aug 2015 00:21:02.0728 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/KpZF0fCMPRjT3gxkXYh-y_VUW0w>
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, 04 Aug 2015 00:21:09 -0000

> use CertificateRequest within the handshake, and the new content type outside of it

Would the client then also use this new content type for Certificate and CertificateVerify messages (when these are sent after the handshake is complete)?

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.23.0 | Report a Bug | By Email