Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F266712D54B; Thu, 7 Apr 2016 21:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 FR86xlGFJDDb; Thu, 7 Apr 2016 21:26:40 -0700 (PDT) Received: from BAY004-OMC1S8.hotmail.com (bay004-omc1s8.hotmail.com [65.54.190.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004F612D571; Thu, 7 Apr 2016 21:26:39 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com ([65.54.190.60]) by BAY004-OMC1S8.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 7 Apr 2016 21:26:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/6kbJc+gGZfeom0xaAfgf7ID+ebujsqhN8k1JnXk6Zg=; b=BmUb/udKZAKka/IV6g4SmZo59NfugFnvAyL7wtYdwB8KCeOOwfVBno7Oc7NWRfNQEoWlWzt23RiuxoVFQ7DmX1lMv19hHVMvdRzVl2pp1SrokP+pi815gy9oVe3QW6rDx5aEwJ8zlqiGADCxivCVIyOF2VTjzEeOr8+ltaoRTJCLyImLLvunzLFpcdeydcfC/m/6KR0LKftMjSMC5GA8wGSCjWU5jtTpn8dSpR8GtPwOCpNW+GAlgsRiUlJaVlQWQyCL3PHLc40DfQ8DtfcJH5H6WDzpgUuQX+ww7rqOWGPjsf9x5kDJL4O7VvDQkc5LbbKtrAYyGyj5+xjpnsZs5A== Received: from SN1NAM02FT023.eop-nam02.prod.protection.outlook.com (10.152.72.58) by SN1NAM02HT176.eop-nam02.prod.protection.outlook.com (10.152.72.72) with Microsoft SMTP Server (TLS) id 15.1.453.6; Fri, 8 Apr 2016 04:26:38 +0000 Received: from CY1PR17MB0425.namprd17.prod.outlook.com (10.152.72.53) by SN1NAM02FT023.mail.protection.outlook.com (10.152.72.156) with Microsoft SMTP Server (TLS) id 15.1.453.6 via Frontend Transport; Fri, 8 Apr 2016 04:26:38 +0000 Received: from CY1PR17MB0425.namprd17.prod.outlook.com ([10.163.253.19]) by CY1PR17MB0425.namprd17.prod.outlook.com ([10.163.253.19]) with mapi id 15.01.0453.027; Fri, 8 Apr 2016 04:26:38 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , 'The IESG' , "draft-ietf-tls-falsestart.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-tls-falsestart-01 Thread-Index: AQHRkU5CJXLqCw+EvEKL+VeVjBl9tw== Date: Fri, 8 Apr 2016 04:26:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 25.152.72.53) smtp.mailfrom=outlook.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=outlook.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning outlook.com discourages use of 25.152.72.53 as permitted sender) x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [17cI8gL6vifuppG16dERS0DiiiXigim9] x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:25.152.72.53; IPV:NLI; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM02HT176; H:CY1PR17MB0425.namprd17.prod.outlook.com; FPR:; SPF:SoftFail; MLV:ovrnspm; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 9bd7d8e3-d888-4b7d-c73d-08d35f65fa12 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5061506196)(5061507196); SRVR:SN1NAM02HT176; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:SN1NAM02HT176; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM02HT176; x-forefront-prvs: 0906E83A25 Content-Type: multipart/alternative; boundary="_000_CY1PR17MB0425B0C73C8904BAD68E6B81DF910CY1PR17MB0425namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2016 04:26:38.0460 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT176 X-OriginalArrivalTime: 08 Apr 2016 04:26:40.0080 (UTC) FILETIME=[D8C63500:01D1914E] Archived-At: Subject: [secdir] Secdir review of draft-ietf-tls-falsestart-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 04:26:42 -0000 --_000_CY1PR17MB0425B0C73C8904BAD68E6B81DF910CY1PR17MB0425namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This document specifies a performance enhancement to TLS that under certain= circumstances could weaken security. Much of the document covers criteria = for when it is "safe" to implement this optimization. It would be an option= al behavior in TLS clients and requires no changes to TLS servers (except s= ee below). This I-D is proposed to be an Experimental RFC. This enhancement has been proposed before, but rejected because of the poss= ible security exposures. Nevertheless, because it can be implemented unilat= erally in the client, I would be surprised if some implementations were not= doing it. The performance benefit is the savings of a network round trip, = which is generally small but it could make a human detectable difference in= the rate at which interactive content loads, and this could be seen as a c= ompetitive advantage. The advantage of having such a document published is that people considerin= g making this change could easily learn the security dangers of doing it an= d make an informed decision. Some nits: Section 3 talks about determining whether a TLS server is "false start comp= atible". I believe any server that correctly implements TLS (i.e., followin= g the specification) would be false start compatible. That does not imply t= hat all would be, and it would be useful to do some testing to see whether = most implementations in fact are. Publishing this as an experimental RFC is= likely to encourage such an effort. Section 2 paragraph 1 says that TLS requires two full protocol rounds befor= e the handshake is complete. While technically this is true, it overstates = the benefit of this enhancement because TLS rides atop TCP which has its ow= n protocol round before it starts carrying application payloads. So this en= hancement reduces that TLS startup time from three round trips to two rathe= r than the more dramatic two to one. --_000_CY1PR17MB0425B0C73C8904BAD68E6B81DF910CY1PR17MB0425namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This document specifies a performance enhancement to TLS that under cert= ain circumstances could weaken security. Much of the document covers criter= ia for when it is "safe" to implement this optimization. It would= be an optional behavior in TLS clients and requires no changes to TLS servers (except see below). This I-D is propose= d to be an Experimental RFC.


This enhancement has been proposed before, but rejected because of the p= ossible security exposures. Nevertheless, because it can be implemented uni= laterally in the client, I would be surprised if some implementations were = not doing it. The performance benefit is the savings of a network round trip, which is generally small but it co= uld make a human detectable difference in the rate at which interactive con= tent loads, and this could be seen as a competitive advantage.


The advantage of having such a document published is that people conside= ring making this change could easily learn the security dangers of doing it= and make an informed decision.


Some nits:


Section 3 talks about determining whether a TLS server is "false st= art compatible". I believe any server that correctly implements TLS (i= .e., following the specification) would be false start compatible. That doe= s not imply that all would be, and it would be useful to do some testing to see whether most implementations in fact a= re. Publishing this as an experimental RFC is likely to encourage such an e= ffort.


Section 2 paragraph 1 says that TLS requires two full protocol rounds be= fore the handshake is complete. While technically this is true, it overstat= es the benefit of this enhancement because TLS rides atop TCP which has its= own protocol round before it starts carrying application payloads. So this enhancement reduces that TLS startu= p time from three round trips to two rather than the more dramatic two to o= ne.


--_000_CY1PR17MB0425B0C73C8904BAD68E6B81DF910CY1PR17MB0425namp_--