From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on070a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe48::70a]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 29D431A1E5C for ; Mon, 1 Aug 2016 18:51:10 -0700 (PDT) Received: from CS1PR84MB0151.NAMPRD84.PROD.OUTLOOK.COM (10.162.189.30) by CS1PR84MB0149.NAMPRD84.PROD.OUTLOOK.COM (10.162.189.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 2 Aug 2016 01:51:08 +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; Tue, 2 Aug 2016 01:51:07 +0000 From: "Palmer, Thomas" To: "Wu, Jiaxin" , "Long, Qin" , "edk2-devel@lists.01.org" CC: "Ye, Ting" , "Fu, Siyuan" , "Gao, Liming" Thread-Topic: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one Thread-Index: AQHR3ZPC2hroSCc030eQHf5GuV9O+KAwDRGAgANeIICAAAcoAIABFJKwgAB57ICAAADCIA== Date: Tue, 2 Aug 2016 01:51:07 +0000 Message-ID: References: <1468475478-145272-1-git-send-email-jiaxin.wu@intel.com> <895558F6EA4E3B41AC93A00D163B7274137C2D07@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137C341E@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <895558F6EA4E3B41AC93A00D163B7274137C341E@SHSMSX103.ccr.corp.intel.com> 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: 98b73702-69d2-461b-dc65-08d3ba7778ad x-microsoft-exchange-diagnostics: 1; CS1PR84MB0149; 6:W8fGDnAATNBPszWK2dl05bN2Qh9wewiDpGIW1R25M/ACh8pzMYomQlMELV20ozWj/+76qByd2Yo5BDYJJ3We5Uhg4EJTeXpeSi1TNyQP+stJCU64hlm2nBjX7/0LjHbmj7mrU6GjP1VmJv3lj78UtIFlEcN3+kHopBRxXHYaYjt1+MZ1ZJhIf7RUvSnIK2GlMvd1z4tzjeadAWIGggLA/7/L2epOOIIbRxtF14RBJo9/PhwO+BxRdY7AXhqb/mX03M5g3EucOrNG0z7IehZYrSAnSJSWOpTT1s7Q/x/0oBiv8VeWT/TnpBzH9WRgpuv/JXadpAm8Z2Sj4dhKSy7C9Q==; 5:xHJQjWnlWfT/KYWTt9rB3eNY9S8jZvGoISEjUNG8FZCCAmoG8FUjO2OMME1rVO402L6WJCApRlQBzOKuil9huKBIUyrjlsRD9pS71AOe3td1lwcshyq2ghQRbAu4ZF9adna36jYj9GPKQlCQTt9tAw==; 24:ddxzfF8topYWIecSErZT7l0xpZA9+Phk0rUfvbC9isFTKWoij2Fq8W7GKh+7dtdGsyhamWVBJN5gn+SsZYdcDOyu8mpN2b4SRdyj3CqpWl4=; 7:vjJqHjscfpiL9E2r+Hhg0UZ8sg38uV9EtoT40ld25SjLrqTURHxPePbvIGTi3okOyn1e5lUZ9vAuBv91UN7HmRs+0W2Qu5zdYvzuWJFA3uGmBVZKWUINI1Ev2p5NZ5m1cNXAYnACM0z3vvQA6nHfnKncKDCZDseHDHBAUdahv5pqSXLMrxOHSx6YwPYJDan9+aEwJoXGPYbau9WiS2VIk8JIBdao26kZBGKYj4WVB19TgMmpLYVHe71Y15Z6KVOj x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CS1PR84MB0149; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227479698468861)(65766998875637)(788757137089)(162533806227266)(36789356921836)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CS1PR84MB0149; BCL:0; PCL:0; RULEID:; SRVR:CS1PR84MB0149; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(13464003)(189002)(377454003)(105586002)(76176999)(50986999)(19580405001)(99286002)(54356999)(9686002)(122556002)(68736007)(586003)(74316002)(102836003)(97736004)(3846002)(6116002)(106356001)(106116001)(66066001)(5002640100001)(2501003)(19580395003)(5001770100001)(7846002)(7736002)(305945005)(7696003)(3900700001)(77096005)(8676002)(81166006)(15975445007)(2950100001)(2900100001)(189998001)(81156014)(101416001)(93886004)(86362001)(3660700001)(3280700002)(10400500002)(33656002)(87936001)(4326007)(561944003)(2906002)(8936002)(92566002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:CS1PR84MB0149; 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: 02 Aug 2016 01:51:07.5644 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR84MB0149 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: Tue, 02 Aug 2016 01:51:10 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jiaxin, It sounds like we both agree that TlsCipherMappingTable is the list of wha= t UEFI officially supports. If it is advertised in TlsCipherMappingTable t= hen OpenSSL needs to support it. My proposal of removing no-dsa / no-idea and adding weak-ciphers is specif= ically aimed to syncing how OpenSSL is configured/built to what is in TlsCi= pherMappingTable. I was busy last week testing out the new ciphers and rea= lized a few were not even getting configured in OpenSSL. =20 Thomas -----Original Message----- From: Wu, Jiaxin [mailto:jiaxin.wu@intel.com]=20 Sent: Monday, August 1, 2016 8:34 PM To: Palmer, Thomas ; Long, Qin ;= 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 Hi Thomas, Since the Tls1.h is used to hold the standardized definitions, openssl part= is not taken into consideration. The Cipher Suites added in Tls1.h only re= fers to A.5 of rfc-2246, rfc-4346 and rfc-5246. The criteria is removing al= l the limited/insecurity/deprecated ones that specified in RFC -- "Note tha= t this mode is vulnerable to man-in-the middle attacks and is therefore dep= recated." I know the IDEA and DES cipher suites are also deprecated in TLS1= .2, but it does means to TLS1.1. So, some of them are still kept in Tls1.h. As for the TlsCipherMappingTable, it takes on the link between Tls1.h defin= ed cipher suites and openssl supported cipher suites. If we eliminate the f= actors of configuration, I believe the cipher suites in TlsCipherMappingTa= ble should be implemented in OpenSSL lib. I haven't check them one by one b= ut openssl official document is referred @ https://www.openssl.org/docs/ma= nmaster/apps/ciphers.html, which gives the lists of TLS cipher suites names= from the relevant specification and their OpenSSL equivalents.=20 If the cipher suites in Tls1.h is not found in TlsCipherMappingTable, EFI_U= NSUPPORTED will be returned. I think it's reasonable. Thanks, Jiaxin > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of=20 > Palmer, Thomas > Sent: Tuesday, August 2, 2016 5:46 AM > To: Long, Qin ; Wu, Jiaxin ;=20 > edk2-devel@lists.01.org > Cc: Ye, Ting ; Fu, Siyuan ;=20 > Gao, Liming > Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS=20 > definitions with the standardized one >=20 > Jiaxin / Qin, >=20 >=20 > I'm unaware of what criteria is required for a cipher to be in this=20 > TlsCipherMappingTable. I had presumed that it would be b/c UEFI=20 > supported the cipher for TLS operation. If unsupported ciphers are=20 > allowed ... then logically wouldn't we need to add all ciphers? What=20 > advantage do we gain by having an entry in this table but not actually us= e the cipher in communication? >=20 > Currently TlsGetCipherString is the only means we have to validate=20 > the cipher string. If a cipher is in the table but not in OpenSSL=20 > lib, then we will provide imperfect feedback if the unsupported cipher=20 > is buried in a list of supported ciphers. OpenSSL will simply use=20 > only the ciphers it supports and quietly drop the unsupported cipher. =20 > A user that inspects the list of set ciphers would be curious why a certa= in cipher was being "dropped" / > "filtered". However, if TlsGetCipherString sees that the cipher is not = in our > mapping table the TlsSetCipherList function will return immediate feedbac= k. >=20 > I'm not enthralled with supporting weak/idea ciphers either. I would=20 > vouch for us removing those ciphers from TlsCipherMappingTable. It is=20 > not our responsibility to document the IANA/Description string=20 > description in code. >=20 > This document > (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1 > .pdf) would be a good list for initial cipher support. We have some=20 > of the ciphers on the list already. Here is the sorted list: >=20 > 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 >=20 > Thomas >=20 > -----Original Message----- > From: Long, Qin [mailto:qin.long@intel.com] > Sent: Sunday, July 31, 2016 8:48 PM > To: Wu, Jiaxin ; Palmer, Thomas=20 > ; edk2-devel@lists.01.org > Cc: Ye, Ting ; Fu, Siyuan ;=20 > Gao, Liming > Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS=20 > definitions with the standardized one >=20 > I personally prefer to keep the current supported cipher suite for our=20 > UEFI- TLS enabling. We can have the full RFC definitions, and platform=20 > specific cipher sets for validation now. It's better to maintain one=20 > minimal scope in this phase. >=20 > "enable-weak-ssl-ciphers" looks odd. Disabling weak ciphers is the=20 > recommendation for hardening SSL communications. > For other ciphers (idea, dsa, etc), we can enable them step-by-step=20 > depending on the real requirements. >=20 >=20 > Best Regards & Thanks, > LONG, Qin >=20 > > -----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 > > > > Thomas, > > I agree some of them are not supported due to the UEFI OpenSSL=20 > > configuration, but it doesn't affect those mapping relationship=20 > > added in the patch. So, I have no strong opinion whether to support=20 > > it by modifying the current OpenSSL configuration. Since Qin is the=20 > > OpenSSL expert, I'd like to hear his views. > > > > Qin, > > What's your opinion? > > > > Thanks. > > Jiaxin > > > > > -----Original Message----- > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On=20 > > > Behalf 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,=20 > > > 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=20 > > > definitions with the standardized one > > > > > > The series patches are used to replace the TLS definitions with=20 > > > the standardized one. In addition, more TLS cipher suite mapping=20 > > > between Cipher Suite definitions and OpenSSL-used Cipher Suite name a= re 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 on= e > > > NetworkPkg/HttpDxe: Replace the definitions with the=20 > > > standardized 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=20 > > > 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 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel