From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe40::710]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 883C81A1E15 for ; Mon, 1 Aug 2016 14:45:41 -0700 (PDT) Received: from CS1PR84MB0151.NAMPRD84.PROD.OUTLOOK.COM (10.162.189.30) by CS1PR84MB0118.NAMPRD84.PROD.OUTLOOK.COM (10.162.189.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 1 Aug 2016 21:45:39 +0000 Received: from CS1PR84MB0151.NAMPRD84.PROD.OUTLOOK.COM ([10.162.189.30]) by CS1PR84MB0151.NAMPRD84.PROD.OUTLOOK.COM ([10.162.189.30]) with mapi id 15.01.0549.022; Mon, 1 Aug 2016 21:45:38 +0000 From: "Palmer, Thomas" To: "Long, Qin" , "Wu, Jiaxin" , "edk2-devel@lists.01.org" CC: "Ye, Ting" , "Fu, Siyuan" , "Gao, Liming" , "Shifflett, Joseph" Thread-Topic: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one Thread-Index: AQHR3ZPC2hroSCc030eQHf5GuV9O+KAwDRGAgANeIICAAAcoAIABFJKw Date: Mon, 1 Aug 2016 21:45:38 +0000 Message-ID: References: <1468475478-145272-1-git-send-email-jiaxin.wu@intel.com> <895558F6EA4E3B41AC93A00D163B7274137C2D07@SHSMSX103.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.palmer@hpe.com; x-originating-ip: [15.203.227.4] x-ms-office365-filtering-correlation-id: 598ae8aa-fe03-41e7-d47e-08d3ba552d7d x-microsoft-exchange-diagnostics: 1; CS1PR84MB0118; 6:QQvtNqgZRO4DU0Lkjc7vNo3FcSkNfp6vTK1GmBILwSrvswePZLZZhxZwHntWwvTW5mT6hXI95d8YXLxIzUQ2kB6FQDGo6PDnC7Y6/5iSdNwVx2I91kRlJ4ZLWVC/f6WhXXbTs/KR6liRPF0RTt05kUrt7R9mBRH6b4PJLz0Rz36vKk8xEsSGejlZfzcMN81VH2fE88LbnCiL0bbB1rpUu0L89StWADe5w61zGKZM09q4BP/kGVphwTtz14tBgJ2+Tw1laR40XONIx767hVzOXiLXa4GmmDDGpFhcvViy+zqM3LEWfHPj0WOunSUwJ8tczjrMJNm2iAzdkiz++aQBTA==; 5:upbRBjhjeblRmaCILfCoDtdOu0CrEOjSlQhrZU3zMlOJpp+ZeWDAgMbyVpwLmBYKfQUM5GnnUYnf2PJgr1EYiUS3lcrngTvQcFl6WzJID9Xh3iCh9TzD9Ya+MXzkgV2wdGhST8wVEHsAiarP+RbEUA==; 24:8eCLtnYkpcdXtPqzfER7kXDUpwadYAV+KnctT8gcA6iYVETqHfiF7YU3apCPmzN8JsVZWT4H3rjw1blcKJUavEIpJ0aMS3N4kJ1vSydcv1U=; 7:8jmp8psQCHuqWTGePr8LjEX6mcIfLH+w5OLL3devNCC0TrTf5QeqFoKn0S/hD96+T8j2P0wvH5PLnB4rGIYisWhdSc9URW9/GV6Xes1r+eyxmk5ji7KKolOXYrwtQK9Z+CUwh1tyoHsebf7rITjn92jDmMp2DJaoHCgLW4DbDyZ4NnJNi11jv7KDXp8r9h60uWyFsIviQZs0n0lxUWLlOZfOTM4ln7GsEDGHfEWOVpfFUuwR7fwk6ghfQqWFzPst x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CS1PR84MB0118; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227479698468861)(65766998875637)(788757137089)(162533806227266)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CS1PR84MB0118; BCL:0; PCL:0; RULEID:; SRVR:CS1PR84MB0118; x-forefront-prvs: 0021920B5A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(377454003)(199003)(189002)(7696003)(7736002)(2950100001)(54356999)(68736007)(7846002)(3900700001)(74316002)(106116001)(106356001)(305945005)(2906002)(2900100001)(122556002)(3280700002)(6116002)(102836003)(77096005)(19580395003)(15975445007)(586003)(10400500002)(8936002)(3846002)(3660700001)(8676002)(9686002)(93886004)(19580405001)(99286002)(81166006)(81156014)(86362001)(97736004)(87936001)(5001770100001)(105586002)(2501003)(66066001)(92566002)(5002640100001)(50986999)(76176999)(189998001)(33656002)(101416001)(4326007)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:CS1PR84MB0118; H:CS1PR84MB0151.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2016 21:45:38.4547 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR84MB0118 Subject: Re: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 21:45:41 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jiaxin / Qin, I'm unaware of what criteria is required for a cipher to be in this TlsCip= herMappingTable. I had presumed that it would be b/c UEFI supported the ci= pher for TLS operation. If unsupported ciphers are allowed ... then logica= lly wouldn't we need to add all ciphers? What advantage do we gain by havi= ng an entry in this table but not actually use the cipher in communication? =09 Currently TlsGetCipherString is the only means we have to validate the cip= her string. If a cipher is in the table but not in OpenSSL lib, then we wi= ll provide imperfect feedback if the unsupported cipher is buried in a list= of supported ciphers. OpenSSL will simply use only the ciphers it support= s and quietly drop the unsupported cipher. A user that inspects the list o= f set ciphers would be curious why a certain cipher was being "dropped" / "= filtered". However, if TlsGetCipherString sees that the cipher is not in = our mapping table the TlsSetCipherList function will return immediate feedb= ack. I'm not enthralled with supporting weak/idea ciphers either. I would vouc= h for us removing those ciphers from TlsCipherMappingTable. It is not our = responsibility to document the IANA/Description string description in code. This document (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S= P.800-52r1.pdf) would be a good list for initial cipher support. We have s= ome of the ciphers on the list already. Here is the sorted list: TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA256 TLS_DH_DSS_WITH_AES_128_GCM_SHA256 TLS_DH_DSS_WITH_AES_256_CBC_SHA TLS_DH_DSS_WITH_AES_256_CBC_SHA256 TLS_DH_DSS_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CCM17 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CCM TLS_RSA_WITH_AES_256_GCM_SHA384 Thomas -----Original Message----- From: Long, Qin [mailto:qin.long@intel.com]=20 Sent: Sunday, July 31, 2016 8:48 PM To: Wu, Jiaxin ; Palmer, Thomas ; edk2-devel@lists.01.org Cc: Ye, Ting ; Fu, Siyuan ; Gao, Li= ming Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions wit= h the standardized one I personally prefer to keep the current supported cipher suite for our UEFI= -TLS enabling. We can have the full RFC definitions, and platform specific = cipher sets for validation now. It's better to maintain one minimal scope i= n this phase. "enable-weak-ssl-ciphers" looks odd. Disabling weak ciphers is the recommen= dation for hardening SSL communications. For other ciphers (idea, dsa, etc), we can enable them step-by-step dependi= ng on the real requirements.=20 Best Regards & Thanks, LONG, Qin > -----Original Message----- > From: Wu, Jiaxin > Sent: Monday, August 01, 2016 9:23 AM > To: Palmer, Thomas; Long, Qin; edk2-devel@lists.01.org > Cc: Ye, Ting; Fu, Siyuan; Gao, Liming > Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS=20 > definitions with the standardized one >=20 > Thomas, > I agree some of them are not supported due to the UEFI OpenSSL=20 > configuration, but it doesn't affect those mapping relationship added=20 > in the patch. So, I have no strong opinion whether to support it by=20 > modifying the current OpenSSL configuration. Since Qin is the OpenSSL=20 > expert, I'd like to hear his views. >=20 > Qin, > What's your opinion? >=20 > Thanks. > Jiaxin >=20 > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf=20 > > Of Palmer, Thomas > > Sent: Saturday, July 30, 2016 6:03 AM > > To: Wu, Jiaxin ; edk2-devel@lists.01.org > > Cc: Ye, Ting ; Fu, Siyuan ;=20 > > Gao, Liming ; Long, Qin > > Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS=20 > > definitions with the standardized one > > > > Jiaxin, > > > > UEFI's OpenSSL library does not support all the ciphers that were=20 > > added in your patch due to the UEFI configuration. We need to=20 > > remove > > "no- idea" and "no-dsa" from the process_files.sh and add > > "enable-weak-ssl- ciphers" > > > > While we are modifying process_files.sh, we can remove "no- > pqueue" > > from process_files.sh so that OpensslLib.inf is in sync. > > > > I can send out a patch to do so if you wish. > > > > Thomas > > > > -----Original Message----- > > From: Jiaxin Wu [mailto:jiaxin.wu@intel.com] > > Sent: Thursday, July 14, 2016 12:51 AM > > To: edk2-devel@lists.01.org > > Cc: Liming Gao ; Palmer, Thomas=20 > > ; Long Qin ; Ye Ting=20 > > ; Fu Siyuan ; Wu Jiaxin=20 > > > > Subject: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions=20 > > with the standardized one > > > > The series patches are used to replace the TLS definitions with the=20 > > standardized one. In addition, more TLS cipher suite mapping between=20 > > Cipher Suite definitions and OpenSSL-used Cipher Suite name are added. > > > > Cc: Liming Gao > > Cc: Palmer Thomas > > Cc: Long Qin > > Cc: Ye Ting > > Cc: Fu Siyuan > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Wu Jiaxin > > Signed-off-by: Jiaxin Wu > > > > Jiaxin Wu (4): > > MdePkg: Add a header to standardize TLS definitions > > CryptoPkg: Add more TLS cipher suite mapping > > NetworkPkg/TlsDxe: Replace the definitions with the standardized one > > NetworkPkg/HttpDxe: Replace the definitions with the standardized=20 > > one > > > > CryptoPkg/Library/TlsLib/TlsLib.c | 3585 ++++++++++++++++--------= ------ > -- > > MdePkg/Include/IndustryStandard/Tls1.h | 93 + > > NetworkPkg/HttpDxe/HttpDriver.h | 2 + > > NetworkPkg/HttpDxe/HttpProto.c | 12 +- > > NetworkPkg/HttpDxe/HttpsSupport.c | 22 +- > > NetworkPkg/HttpDxe/HttpsSupport.h | 44 - > > NetworkPkg/TlsDxe/TlsImpl.c | 56 +- > > NetworkPkg/TlsDxe/TlsImpl.h | 30 +- > > NetworkPkg/TlsDxe/TlsProtocol.c | 2 +- > > 9 files changed, 1945 insertions(+), 1901 deletions(-) create mode > > 100644 MdePkg/Include/IndustryStandard/Tls1.h > > > > -- > > 1.9.5.msysgit.1 > > > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel