From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.24; helo=mga09.intel.com; envelope-from=jiaxin.wu@intel.com; receiver=edk2-devel@lists.01.org Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id BD27121E48F50 for ; Tue, 23 Jan 2018 22:46:59 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2018 22:52:26 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,405,1511856000"; d="scan'208";a="168687965" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga004.jf.intel.com with ESMTP; 23 Jan 2018 22:52:24 -0800 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 23 Jan 2018 22:51:48 -0800 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 23 Jan 2018 22:51:47 -0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.213]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.152]) with mapi id 14.03.0319.002; Wed, 24 Jan 2018 14:50:26 +0800 From: "Wu, Jiaxin" To: Laszlo Ersek , "Fu, Siyuan" , "Ye, Ting" , "Long, Qin" , "Yao, Jiewen" , "Hsiung, Harry L" CC: edk2-devel-01 Thread-Topic: setting the TLS cipher list for HTTPS booting Thread-Index: AQHTkTKC7SSIQqPfwE6mEzdxVropQKN8Nf+ggALqwACAAZWo0IAARlKAgAAQ6YCAATdDQIAAHRVggAA0GHA= Date: Wed, 24 Jan 2018 06:50:25 +0000 Message-ID: <895558F6EA4E3B41AC93A00D163B72741635F9AF@SHSMSX103.ccr.corp.intel.com> References: <5307d880-d016-ad91-04f5-6b83eb40f905@redhat.com> <895558F6EA4E3B41AC93A00D163B72741635E571@SHSMSX103.ccr.corp.intel.com> <7b529d2c-1e46-3bd5-d8a6-9225a630f23b@redhat.com> <895558F6EA4E3B41AC93A00D163B72741635F0B5@SHSMSX103.ccr.corp.intel.com> <366c3083-0eb1-ecb4-2050-654c09135f8a@redhat.com> <93bf358e-7e57-a0f0-b8ba-239e72036c27@redhat.com> <895558F6EA4E3B41AC93A00D163B72741635F6BC@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B72741635F7FE@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <895558F6EA4E3B41AC93A00D163B72741635F7FE@SHSMSX103.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODg5MWE5NzMtMzAyZC00NTM4LTg3OGEtZjRhZjBmZWQ1Y2IxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6Iks4bUdUK1ArSGd6NHBUa2tqV1A0K0pabGgrVzdBWUNaQ0hPc1k4ZnRWMXM9In0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: setting the TLS cipher list for HTTPS booting X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 06:47:00 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Laszlo, After the discussion with team member, we still prefer to use the PCD solut= ion. In HttpDxe driver, we don't want to locate/use a nonstandard protocol.= We think It's not a general solution for the UEFI driver. =20 Thanks, Jiaxin > -----Original Message----- > From: Wu, Jiaxin > Sent: Wednesday, January 24, 2018 11:40 AM > To: Wu, Jiaxin ; Laszlo Ersek ; F= u, > Siyuan ; Ye, Ting ; Long, Qin > ; Yao, Jiewen ; Hsiung, Harry L > > Cc: edk2-devel-01 > Subject: RE: setting the TLS cipher list for HTTPS booting >=20 > Hi Laszlo, >=20 > More comments: >=20 > > > > Dynamic PCDs is just one of the solutions for the required settings, ju= st like > the > > platform protocol (HTTPS_CONFIG_PROTOCOL), provides the capability to > > support the global HTTPS configuration. > > > > Each solutions have its own advantages and disadvantages: > > 1) PCD can simplify the problem and it's easy to use for the other plat= form > not > > only OVMF, but as you said, it's perhaps overkill. > > 2) The additional platform protocol looks flexible and reasonably, but = it > makes > > the specific platform have the optional dependency ["OVMF hooks a NULL- > class > > library into HttpDxe that introduces a new DEPEX on the protocol. Other > > platforms would not delay HttpDxe."]. If the user doesn't want HTTPS fe= ature > > but only HTTP, it has to include one NULL protocol. > > >=20 > I checked the PciHostBridgeDxe driver to call the EDKII_IOMMU_PROTOCOL, > which makes me better understanding your comments. >=20 > MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf { > > ... > NULL|OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf > } >=20 > So, as you said, it's just the platform behavior so as to hook the platfo= rm > produces the EDKII_IOMMU_PROTOCOL protocol first, then dispatch > PciHostBridgeDxe driver. That's good to me. >=20 > For HTTPS configuration, the HttpDxe configuration is only happened durin= g the > protocol instance calling, which is created by service binding protocol. = So, it > looks only happened after EndofDxe phase. If so, it will be no such optio= nal > dependency to wait for the platform DXE driver produces the > EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL. >=20 > Anyway, for above two solutions, I need review them with other colleagues= and > help to collect the comments for both of them, then feedback to you. Than= k you > so such. >=20 >=20 > > Now, I think we are discussing the most appropriate way for the HTTPS > > controlling. It's NOT related to who should be responsible for the solu= tion > > coding, you know we are always thinking from the user's perspective:). > > > > > > > > > > > > If you really think that HttpDxe should only care about these two i= tems > > > > (CA cert and cipher list), then I have another question: do you thi= nk it > > > > makes sense to introduce another non-volatile UEFI variable, for th= e > > > > cipher suites too? This would make things uniform, and perhaps > > > > TlsAuthConfigDxe could expose the cipher suites too, as a list of > > > > checkboxes. Just an idea. > > > > > > So, apparently we indeed care about these two options mostly, i.e., t= he > > > CA certs, and the cipher suites. > > > > > > However, I was informed that OVMF should simply forward the *textual* > > > cipher list representation, with preferably no processing at all befo= re > > > the string reaches the OpenSSL code. In other words, OVMF should set = the > > > PCD -- or, even better, variable -- to a *character string* like this= : > > > > > > > > > "kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:!EXP:!DES:!RC4:!RC2:!IDEA:!SEE > > > D:!eNULL:!aNULL:!MD5:!SSLv2" > > > > > > Is this feasible? > > > > It looks impossible to simply forward the *textual*cipher list to OpenS= SL from > > the aspect of EFI_TLS_PROTOCOL. > > > > //************************************************************ > > // EFI_TLS_CIPHER > > //************************************************************ > > typedef struct { > > UINT8 Data1; > > UINT8 Data2; > > } EFI_TLS_CIPHER; > > Note: The definition of EFI_TLS_CIPHER is from RFC 5246 A.4.1.Hello > Messages. > > The value of > > EFI_TLS_CIPHER is from TLS Cipher Suite Registry of IANA. > > > > > > > > > > Thanks, > > > Laszlo > > > > >=20 >=20 > Thanks, > Jiaxin