setting the TLS cipher list for HTTPS booting

setting the TLS cipher list for HTTPS booting

[Laszlo Ersek]

Hello Jiaxin, Siyuan,

it seems that the "preferred set of ciphers" can be controlled at the
TLS session level.

With regard to HTTPS booting, "NetworkPkg/HttpDxe" makes several calls
to EFI_TLS_PROTOCOL.SetSessionData() -- in the file
"NetworkPkg/HttpDxe/HttpsSupport.c", -- but it never passes
"EfiTlsCipherList" as argument for the "DataType" parameter.

Is there a way for platform code to control the list of ciphers?

This is different from other "global" TLS aspects, such as
EFI_TLS_CONFIGURATION_PROTOCOL, because the latter is a singleton
"service" protocol, while EFI_TLS_PROTOCOL instances are created by
clients as-needed, via TLS service binding. So, I think if a platform
wanted to control this on the session level, then it would have to "ask"
HttpDxe somehow.

If you agree -- do you suggest a dynamic PCD, or an extension to the
UEFI spec (at the HTTP level)?

Thanks!
Laszlo

Re: setting the TLS cipher list for HTTPS booting

[Wu, Jiaxin]

> 
> Hello Jiaxin, Siyuan,
> 
> it seems that the "preferred set of ciphers" can be controlled at the
> TLS session level.


Jiaxin: Yes, TLS CipherList can be configured by TLS protocol.  


> 
> With regard to HTTPS booting, "NetworkPkg/HttpDxe" makes several calls
> to EFI_TLS_PROTOCOL.SetSessionData() -- in the file
> "NetworkPkg/HttpDxe/HttpsSupport.c", -- but it never passes
> "EfiTlsCipherList" as argument for the "DataType" parameter.
> 


Jiaxin: Correct, currently, HttpDxe as a TLS protocol consumer doesn't set the its own preferred CipherList because it prefers to use the default CipherList, which has been configured by TLS driver by default. The TLS default setting was happened during the creation  of new OpenSSL SSL_CTX object. The flow path is shown as below: 
TlsCtxNew -> SSL_CTX_new -> ssl_create_cipher_list. 
So, the default CipherList is:
 # define SSL_DEFAULT_CIPHER_LIST "ALL:!COMPLEMENTOFDEFAULT:!eNULL"


> Is there a way for platform code to control the list of ciphers?


Jiaxin: Currently, not support yet.


> 
> This is different from other "global" TLS aspects, such as
> EFI_TLS_CONFIGURATION_PROTOCOL, because the latter is a singleton
> "service" protocol, while EFI_TLS_PROTOCOL instances are created by
> clients as-needed, via TLS service binding. So, I think if a platform
> wanted to control this on the session level, then it would have to "ask"
> HttpDxe somehow.
> 


Jiaxin: EFI_TLS_CONFIGURATION_PROTOCOL provides the capability to set the client certificate/key pairs, different clients may use the different certificate/key Paris (so does OpenSSL). Based on this, it's not a singleton "service" protocol. So, in TlsDxe driver, we bind it to the same ChildHandle as TLS protocol.
  Status = gBS->InstallMultipleProtocolInterfaces (
                  ChildHandle,
                  &gEfiTlsProtocolGuid,
                  &TlsInstance->Tls,
                  &gEfiTlsConfigurationProtocolGuid,
                  &TlsInstance->TlsConfig,
                  NULL
                  );
But above implementation also doesn't prevent all the clients use the same certificate/key Paris since they can use its own EFI_TLS_CONFIGURATION_PROTOCOL to configure the same "global" certificate/key pair (on the session level). That's depend on the TLS consumer.


> If you agree -- do you suggest a dynamic PCD, or an extension to the
> UEFI spec (at the HTTP level)?
> 


Jiaxin: I agree with the dynamic PCD solution for the CipherList setting, the PCD format can use as following one:
	gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists |{0x0}|VOID*|0x0000000D
If the platform wants to set the below CipherSuites (RFC 5246 defined):
	CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 }; 
	CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D };
The PCD can be configured by the corresponding platform as below, otherwise it will use the OpenSSL default one:
	gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists |{0x00,0x35, 0x00,0x3D }|VOID*|4
what do you think?

> Thanks!
> Laszlo

Re: setting the TLS cipher list for HTTPS booting

[Laszlo Ersek]

On 01/20/18 07:18, Wu, Jiaxin wrote:
>>
>> Hello Jiaxin, Siyuan,
>>
>> it seems that the "preferred set of ciphers" can be controlled at the
>> TLS session level.
>
>
> Jiaxin: Yes, TLS CipherList can be configured by TLS protocol.
>
>
>>
>> With regard to HTTPS booting, "NetworkPkg/HttpDxe" makes several
>> calls to EFI_TLS_PROTOCOL.SetSessionData() -- in the file
>> "NetworkPkg/HttpDxe/HttpsSupport.c", -- but it never passes
>> "EfiTlsCipherList" as argument for the "DataType" parameter.
>>
>
>
> Jiaxin: Correct, currently, HttpDxe as a TLS protocol consumer doesn't
> set the its own preferred CipherList because it prefers to use the
> default CipherList, which has been configured by TLS driver by
> default. The TLS default setting was happened during the creation  of
> new OpenSSL SSL_CTX object. The flow path is shown as below:
> TlsCtxNew -> SSL_CTX_new -> ssl_create_cipher_list.
> So, the default CipherList is:
>  # define SSL_DEFAULT_CIPHER_LIST "ALL:!COMPLEMENTOFDEFAULT:!eNULL"
>
>
>> Is there a way for platform code to control the list of ciphers?
>
>
> Jiaxin: Currently, not support yet.
>
>
>>
>> This is different from other "global" TLS aspects, such as
>> EFI_TLS_CONFIGURATION_PROTOCOL, because the latter is a singleton
>> "service" protocol, while EFI_TLS_PROTOCOL instances are created by
>> clients as-needed, via TLS service binding. So, I think if a platform
>> wanted to control this on the session level, then it would have to
>> "ask" HttpDxe somehow.
>>
>
>
> Jiaxin: EFI_TLS_CONFIGURATION_PROTOCOL provides the capability to set
> the client certificate/key pairs, different clients may use the
> different certificate/key Paris (so does OpenSSL). Based on this, it's
> not a singleton "service" protocol. So, in TlsDxe driver, we bind it
> to the same ChildHandle as TLS protocol.
>   Status = gBS->InstallMultipleProtocolInterfaces (
>                   ChildHandle,
>                   &gEfiTlsProtocolGuid,
>                   &TlsInstance->Tls,
>                   &gEfiTlsConfigurationProtocolGuid,
>                   &TlsInstance->TlsConfig,
>                   NULL
>                   );
> But above implementation also doesn't prevent all the clients use the
> same certificate/key Paris since they can use its own
> EFI_TLS_CONFIGURATION_PROTOCOL to configure the same "global"
> certificate/key pair (on the session level). That's depend on the TLS
> consumer.

Thank you for the correction.

Do I understand correctly that, consequently, these characteristics have
to be set in NetworkPkg/HttpDxe as well, similarly to the cipher list?

If that's correct, what would be the best way for a platform to control
these settings? Introducing separate dynamic PCDs is perhaps overkill.

Sometimes platform customization is implemented by the core module
calling out to an optional platform-provided protocol.

For example, PciHostBridgeDxe calls EDKII_IOMMU_PROTOCOL, if the
platform provides one.

Alternatively, PciBusDxe calls EFI_PCI_HOT_PLUG_INIT_PROTOCOL, if the
platform provides one.

Can we introduce a similar protocol here, so that HttpDxe can ask the
platform about the TLS preferences, and then configure TLS accordingly?


Sticking with the IOMMU example: in OVMF, we don't *always* have an
IOMMU protocol, but when we do, then we want PciHostBridgeDxe to wait
for the protocol (with a depex). So what we do is, we have a very small
library instance,

  OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf

with an empty constructor, and a DEPEX like this:

[Depex]
  gEdkiiIoMmuProtocolGuid OR gIoMmuAbsentProtocolGuid

(The latter protocol is from OvmfPkg.dec.)

Then, in the OVMF DSC files, we hook this library into PciHostBridgeDxe,
as a NULL class library. The end result is that PciHostBridgeDxe will
only be dispatched after OVMF platform code determines whether an IOMMU
is present or not. If not, then gIoMmuAbsentProtocolGuid is installed
(and PciHostBridgeDxe will be launched without an IOMMU). Otherwise
gEdkiiIoMmuProtocolGuid is installed by OVMF, and then PciHostBridgeDxe
is guaranteed to use the IOMMU.

In the HTTPS boot case, I'd make HttpDxe wait for the platform TLS
settings similarly -- NetworkPkg/HttpDxe would only have to look up the
protocol, and use it (for configuring TLS) if the protocol is there.

This looks more flexible than a large set of dynamic PCDs.

... We have such names already:

  EDKII_PLATFORM_LOGO_PROTOCOL
  EDKII_PLATFORM_VTD_POLICY_PROTOCOL

So we could introduce EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL, with the
following member functions:

  .GetData ()
  .GetSessionData ()

They would have similar signatures to
EFI_TLS_CONFIGURATION_PROTOCOL.GetData() and
EFI_TLS_PROTOCOL.GetSessionData().

"NetworkPkg/HttpDxe" could call each of these functions in a loop
(iterating over EFI_TLS_CONFIG_DATA_TYPE and EFI_TLS_SESSION_DATA_TYPE,
up to EfiTlsConfigDataTypeMaximum and EfiTlsSessionDataTypeMaximum,
respectively). If the platform has nothing to say about a given item, it
returns EFI_UNSUPPORTED. Otherwise, the platform returns the data that
the platform would like HttpDxe to set for that TLS setting.


>
>> If you agree -- do you suggest a dynamic PCD, or an extension to the
>> UEFI spec (at the HTTP level)?
>
>
> Jiaxin: I agree with the dynamic PCD solution for the CipherList
> setting, the PCD format can use as following one:
> 	gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists |{0x0}|VOID*|0x0000000D
> If the platform wants to set the below CipherSuites (RFC 5246
> defined):
> 	CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 };
> 	CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D };
> The PCD can be configured by the corresponding platform as below,
> otherwise it will use the OpenSSL default one:
> 	gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists |{0x00,0x35, 0x00,0x3D }|VOID*|4
> what do you think?

I feel the platform protocol could be more flexible and extensible.

Thank you!
Laszlo

Re: setting the TLS cipher list for HTTPS booting

[Wu, Jiaxin]

> >>
> >> Hello Jiaxin, Siyuan,
> >>
> >> it seems that the "preferred set of ciphers" can be controlled at the
> >> TLS session level.
> >
> >
> > Jiaxin: Yes, TLS CipherList can be configured by TLS protocol.
> >
> >
> >>
> >> With regard to HTTPS booting, "NetworkPkg/HttpDxe" makes several
> >> calls to EFI_TLS_PROTOCOL.SetSessionData() -- in the file
> >> "NetworkPkg/HttpDxe/HttpsSupport.c", -- but it never passes
> >> "EfiTlsCipherList" as argument for the "DataType" parameter.
> >>
> >
> >
> > Jiaxin: Correct, currently, HttpDxe as a TLS protocol consumer doesn't
> > set the its own preferred CipherList because it prefers to use the
> > default CipherList, which has been configured by TLS driver by
> > default. The TLS default setting was happened during the creation  of
> > new OpenSSL SSL_CTX object. The flow path is shown as below:
> > TlsCtxNew -> SSL_CTX_new -> ssl_create_cipher_list.
> > So, the default CipherList is:
> >  # define SSL_DEFAULT_CIPHER_LIST
> "ALL:!COMPLEMENTOFDEFAULT:!eNULL"
> >
> >
> >> Is there a way for platform code to control the list of ciphers?
> >
> >
> > Jiaxin: Currently, not support yet.
> >
> >
> >>
> >> This is different from other "global" TLS aspects, such as
> >> EFI_TLS_CONFIGURATION_PROTOCOL, because the latter is a singleton
> >> "service" protocol, while EFI_TLS_PROTOCOL instances are created by
> >> clients as-needed, via TLS service binding. So, I think if a platform
> >> wanted to control this on the session level, then it would have to
> >> "ask" HttpDxe somehow.
> >>
> >
> >
> > Jiaxin: EFI_TLS_CONFIGURATION_PROTOCOL provides the capability to set
> > the client certificate/key pairs, different clients may use the
> > different certificate/key Paris (so does OpenSSL). Based on this, it's
> > not a singleton "service" protocol. So, in TlsDxe driver, we bind it
> > to the same ChildHandle as TLS protocol.
> >   Status = gBS->InstallMultipleProtocolInterfaces (
> >                   ChildHandle,
> >                   &gEfiTlsProtocolGuid,
> >                   &TlsInstance->Tls,
> >                   &gEfiTlsConfigurationProtocolGuid,
> >                   &TlsInstance->TlsConfig,
> >                   NULL
> >                   );
> > But above implementation also doesn't prevent all the clients use the
> > same certificate/key Paris since they can use its own
> > EFI_TLS_CONFIGURATION_PROTOCOL to configure the same "global"
> > certificate/key pair (on the session level). That's depend on the TLS
> > consumer.
> 
> Thank you for the correction.
> 
> Do I understand correctly that, consequently, these characteristics have
> to be set in NetworkPkg/HttpDxe as well, similarly to the cipher list?
> 

Yes. They should be set in HttpDxe driver since it's the TLS driver consumer.


> If that's correct, what would be the best way for a platform to control
> these settings? Introducing separate dynamic PCDs is perhaps overkill.
> 
> Sometimes platform customization is implemented by the core module
> calling out to an optional platform-provided protocol.
> 
> For example, PciHostBridgeDxe calls EDKII_IOMMU_PROTOCOL, if the
> platform provides one.
> 
> Alternatively, PciBusDxe calls EFI_PCI_HOT_PLUG_INIT_PROTOCOL, if the
> platform provides one.
> 
> Can we introduce a similar protocol here, so that HttpDxe can ask the
> platform about the TLS preferences, and then configure TLS accordingly?
> 
> 
> Sticking with the IOMMU example: in OVMF, we don't *always* have an
> IOMMU protocol, but when we do, then we want PciHostBridgeDxe to wait
> for the protocol (with a depex). So what we do is, we have a very small
> library instance,
> 
>   OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf
> 
> with an empty constructor, and a DEPEX like this:
> 
> [Depex]
>   gEdkiiIoMmuProtocolGuid OR gIoMmuAbsentProtocolGuid
> 
> (The latter protocol is from OvmfPkg.dec.)
> 
> Then, in the OVMF DSC files, we hook this library into PciHostBridgeDxe,
> as a NULL class library. The end result is that PciHostBridgeDxe will
> only be dispatched after OVMF platform code determines whether an IOMMU
> is present or not. If not, then gIoMmuAbsentProtocolGuid is installed
> (and PciHostBridgeDxe will be launched without an IOMMU). Otherwise
> gEdkiiIoMmuProtocolGuid is installed by OVMF, and then PciHostBridgeDxe
> is guaranteed to use the IOMMU.
> 
> In the HTTPS boot case, I'd make HttpDxe wait for the platform TLS
> settings similarly -- NetworkPkg/HttpDxe would only have to look up the
> protocol, and use it (for configuring TLS) if the protocol is there.
> 
> This looks more flexible than a large set of dynamic PCDs.
> 
> ... We have such names already:
> 
>   EDKII_PLATFORM_LOGO_PROTOCOL
>   EDKII_PLATFORM_VTD_POLICY_PROTOCOL
> 
> So we could introduce EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL, with the
> following member functions:
> 
>   .GetData ()
>   .GetSessionData ()
> 
> They would have similar signatures to
> EFI_TLS_CONFIGURATION_PROTOCOL.GetData() and
> EFI_TLS_PROTOCOL.GetSessionData().
> 
> "NetworkPkg/HttpDxe" could call each of these functions in a loop
> (iterating over EFI_TLS_CONFIG_DATA_TYPE and EFI_TLS_SESSION_DATA_TYPE,
> up to EfiTlsConfigDataTypeMaximum and EfiTlsSessionDataTypeMaximum,
> respectively). If the platform has nothing to say about a given item, it
> returns EFI_UNSUPPORTED. Otherwise, the platform returns the data that
> the platform would like HttpDxe to set for that TLS setting.
> 
> 

With above solution, if I understand correctly, the specific platform needs to produce such a "EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL", which will be consumed by HttpDxe driver. If not existed, EFI_UNSUPPORTED returned. That's totally a incompatibility change compared to the current solution.
Currently, we only support the EfiTlsConfigDataTypeCACertificate since it's the only requirement of HTTPS one-way authentication. To support that, Private variable is used to configure this CA certificate:
	#define EFI_TLS_CA_CERTIFICATE_VARIABLE          L"TlsCaCertificate"
Then, HttpDxe instance will retrieve the variable to configure CACertificate via EFI_TLS_CONFIGURATION_PROTOCOL. For compatibility issue, we must take it into consideration.

Besides, all the configuration data are retrieved from platform protocol instead of the PCD directly, which makes the platform/HttpDxe have more dependency undeniably. 

At the same time, it will impact the *HTTP* feature since the driver is only dispatched after platform determines whether the "EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL" is present or not.  That's looks so weird if we bind the HTTPS_CONFIG_PROTOCOL to *HTTP* feature.


> >
> >> If you agree -- do you suggest a dynamic PCD, or an extension to the
> >> UEFI spec (at the HTTP level)?
> >
> >
> > Jiaxin: I agree with the dynamic PCD solution for the CipherList
> > setting, the PCD format can use as following one:
> > 	gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists
> |{0x0}|VOID*|0x0000000D
> > If the platform wants to set the below CipherSuites (RFC 5246
> > defined):
> > 	CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 };
> > 	CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D };
> > The PCD can be configured by the corresponding platform as below,
> > otherwise it will use the OpenSSL default one:
> > 	gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists |{0x00,0x35,
> 0x00,0x3D }|VOID*|4
> > what do you think?
> 
> I feel the platform protocol could be more flexible and extensible.
> 

PCD defined in NetworkPkg is more like a general solution per HttpDxe driver, it's easy and use directly, without so much dependency and feature impact. So, I still prefer PCD solution.


> Thank you!
> Laszlo

Re: setting the TLS cipher list for HTTPS booting

[Laszlo Ersek]

Hi Jiaxin,

> With above solution, if I understand correctly, the specific platform
> needs to produce such a "EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL", which
> will be consumed by HttpDxe driver.

Yes, that's the idea.


> If not existed, EFI_UNSUPPORTED returned. That's totally a
> incompatibility change compared to the current solution.

I understand that EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL is new to the
HttpDxe driver. However, it does not *have* to be incompatible with the
current logic:

- HttpDxe could simply call gBS->LocateProtocol(). If the protocol is
  not found, simply do whatever the driver does right now.

- If the protocol is found, then don't use the current logic. Instead,
  first call HttpsConfig->GetData() in a loop, and then second, call
  HttpsConfig->GetSessionData() in a loop. For each such call:

  - If the call succeeded, pass the retrieved data to
    EFI_TLS_CONFIGURATION_PROTOCOL.SetData() or
    EFI_TLS_PROTOCOL.SetSessionData, as appropriate.

  - If the call failed with EFI_UNSUPPORTED, simply skip the current
    EFI_TLS_CONFIG_DATA_TYPE or EFI_TLS_SESSION_DATA_TYPE value, and
    continue with the rest of the loop.

  - If the call fails with any other reason, log an error message and
    abort the loop.

In the high level control flow, it is a simple LocateProtocol() call,
and checking whether it succeeds.


> Currently, we only support the EfiTlsConfigDataTypeCACertificate since
> it's the only requirement of HTTPS one-way authentication. To support
> that, Private variable is used to configure this CA certificate:
> 	#define EFI_TLS_CA_CERTIFICATE_VARIABLE          L"TlsCaCertificate"
> Then, HttpDxe instance will retrieve the variable to configure
> CACertificate via EFI_TLS_CONFIGURATION_PROTOCOL. For compatibility
> issue, we must take it into consideration.

OVMF can use this variable. It is possible to write a DXE driver for
OVMF that waits for the Variable Write Arch Protocol, sets the
"TlsCaCertificate" variable as necessary, and then installs a custom
NULL protocol in the protcol database. In turn the OVMF DSC file can
make "HttpDxe" wait for this new NULL protocol, with a DEPEX.

(Alternatively, we can plug a NULL-class library into HttpDxe that sets
the variable just before HttpDxe starts.)

My issue is not with the functionality; the problem is that OVMF users
will want to control many other aspects of TLS (for HTTPS booting), not
just the CA certificate for one-way authentication, and the TLS cipher
suites. For example, they might want to specify a revocation list, the
TLS compression method, and so on.

We cannot tell in advance what other TLS configuration knobs will be
introduced in the future. OVMF does not have any TLS preferences of its
own, it just needs to propagate the TLS preferences that the end-user
has already configured on the virtualization *host*. Basically the user
sets up TLS on the host computer in some way, and then libvirt (which
manages QEMU), QEMU (which runs the guest), and OVMF collaborate so that
the same TLS settings take effect for HTTPS booting. If there are 10
guests on the same host computer, then the TLS configuration on the host
should apply to HTTPS boot in all the guests.

This is why I suggested the loops. If HttpDxe calls
EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL.Get*() for all enumeration values,
then we don't have to add new UEFI variables or PCDs when a new item
appears. The EfiTls*Maximum enum constants will be bumped, and the loops
will cover the new items.


> Besides, all the configuration data are retrieved from platform
> protocol instead of the PCD directly, which makes the platform/HttpDxe
> have more dependency undeniably.

The suggestion is about an optional dependency. HttpDxe does not have to
wait for the protocol; I'm not suggesting a protocol notify, or a DEPEX
for the driver itself. We'll take care of the DEPEX in the OVMF DSC
file. The driver only needs a LocateProtocol() call.


> At the same time, it will impact the *HTTP* feature since the driver
> is only dispatched after platform determines whether the
> "EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL" is present or not.

This is not precise; the dispatch is delayed only if the platform DSC
hooks a NULL-class library into HttpDxe that introduces a new DEPEX on
the protocol.

Other platforms would not delay HttpDxe. The LocateProtocol() call would
fail and the driver would continue working like before.

This is the same pattern that is used with the edk2 IOMMU protocol.


> That's looks so weird if we bind the HTTPS_CONFIG_PROTOCOL to *HTTP*
> feature.

I think the LocateProtocol() call should be fine. HttpDxe covers both
HTTP and HTTPS, and only the HTTP part is optional (via
PcdAllowHttpConnections). The HTTPS part is always there. So checking
for EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL would be just another aspect
for TLS configuration.


>>>> If you agree -- do you suggest a dynamic PCD, or an extension to
>>>> the UEFI spec (at the HTTP level)?
>>>
>>>
>>> Jiaxin: I agree with the dynamic PCD solution for the CipherList
>>> setting, the PCD format can use as following one:
>>> 	gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists
>> |{0x0}|VOID*|0x0000000D
>>> If the platform wants to set the below CipherSuites (RFC 5246
>>> defined):
>>> 	CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 };
>>> 	CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D };
>>> The PCD can be configured by the corresponding platform as below,
>>> otherwise it will use the OpenSSL default one:
>>> 	gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists |{0x00,0x35,
>> 0x00,0x3D }|VOID*|4
>>> what do you think?
>>
>> I feel the platform protocol could be more flexible and extensible.
>>
>
> PCD defined in NetworkPkg is more like a general solution per HttpDxe
> driver, it's easy and use directly, without so much dependency and
> feature impact. So, I still prefer PCD solution.

Functionally, I agree that OVMF can make the feature work, without any
changes to the HttpDxe driver, *but* only for the following two
configuration items:

- CA certificate, through the (already existing) non-volatile UEFI
  variable

- cipher suites (through the new dynamic PCD called
  "PcdHttpsTlsCipherLists")

What about the rest of the configuration items? Should we introduce
dynamic PCDs for those as well, individually?

I cannot tell what other config items should be exposed right from the
start. That's why I'm suggesting HTTPS_CONFIG_PROTOCOL -- it looks
flexible and reasonably future-proof.

BTW, I'm not asking that you write any code for this; I plan to submit
the patches myself (for HttpDxe as well). We just have to figure out the
direction first.


If you really think that HttpDxe should only care about these two items
(CA cert and cipher list), then I have another question: do you think it
makes sense to introduce another non-volatile UEFI variable, for the
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.

Thanks!
Laszlo

Re: setting the TLS cipher list for HTTPS booting

[Laszlo Ersek]

Hi Jiaxin,

two updates:

>>>> Jiaxin: I agree with the dynamic PCD solution for the CipherList
>>>> setting, the PCD format can use as following one:
>>>> 	gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists
>>> |{0x0}|VOID*|0x0000000D
>>>> If the platform wants to set the below CipherSuites (RFC 5246
>>>> defined):
>>>> 	CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 };
>>>> 	CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D };
>>>> The PCD can be configured by the corresponding platform as below,
>>>> otherwise it will use the OpenSSL default one:
>>>> 	gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists |{0x00,0x35,
>>> 0x00,0x3D }|VOID*|4
>>>> what do you think?

> Functionally, I agree that OVMF can make the feature work, without any
> changes to the HttpDxe driver, *but* only for the following two
> configuration items:
> 
> - CA certificate, through the (already existing) non-volatile UEFI
>   variable
> 
> - cipher suites (through the new dynamic PCD called
>   "PcdHttpsTlsCipherLists")
> 
> What about the rest of the configuration items? Should we introduce
> dynamic PCDs for those as well, individually?
> 
> I cannot tell what other config items should be exposed right from the
> start. That's why I'm suggesting HTTPS_CONFIG_PROTOCOL -- it looks
> flexible and reasonably future-proof.
> 
> BTW, I'm not asking that you write any code for this; I plan to submit
> the patches myself (for HttpDxe as well). We just have to figure out the
> direction first.
> 
> 
> If you really think that HttpDxe should only care about these two items
> (CA cert and cipher list), then I have another question: do you think it
> makes sense to introduce another non-volatile UEFI variable, for the
> 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., the
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 before
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:!SEED:!eNULL:!aNULL:!MD5:!SSLv2"

Is this feasible?

Thanks,
Laszlo

Re: setting the TLS cipher list for HTTPS booting

[Wu, Jiaxin]

Hi Laszlo,

> >>>> Jiaxin: I agree with the dynamic PCD solution for the CipherList
> >>>> setting, the PCD format can use as following one:
> >>>> 	gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists
> >>> |{0x0}|VOID*|0x0000000D
> >>>> If the platform wants to set the below CipherSuites (RFC 5246
> >>>> defined):
> >>>> 	CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 };
> >>>> 	CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D };
> >>>> The PCD can be configured by the corresponding platform as below,
> >>>> otherwise it will use the OpenSSL default one:
> >>>> 	gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists |{0x00,0x35,
> >>> 0x00,0x3D }|VOID*|4
> >>>> what do you think?
> 
> > Functionally, I agree that OVMF can make the feature work, without any
> > changes to the HttpDxe driver, *but* only for the following two
> > configuration items:
> >
> > - CA certificate, through the (already existing) non-volatile UEFI
> >   variable
> >
> > - cipher suites (through the new dynamic PCD called
> >   "PcdHttpsTlsCipherLists")
> >
> > What about the rest of the configuration items? Should we introduce
> > dynamic PCDs for those as well, individually?
> >
> > I cannot tell what other config items should be exposed right from the
> > start. That's why I'm suggesting HTTPS_CONFIG_PROTOCOL -- it looks
> > flexible and reasonably future-proof.
> >
> > BTW, I'm not asking that you write any code for this; I plan to submit
> > the patches myself (for HttpDxe as well). We just have to figure out the
> > direction first.
> >

Dynamic PCDs is just one of the solutions for the required settings, just 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 platform 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 feature but only HTTP, it has to include one NULL protocol. 

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 solution coding, you know we are always thinking from the user's perspective:).


> >
> > If you really think that HttpDxe should only care about these two items
> > (CA cert and cipher list), then I have another question: do you think it
> > makes sense to introduce another non-volatile UEFI variable, for the
> > 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., the
> 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 before
> 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 OpenSSL 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


Thanks,
Jiaxin

Re: setting the TLS cipher list for HTTPS booting

[Wu, Jiaxin]

Hi Laszlo,

More comments:

> 
> Dynamic PCDs is just one of the solutions for the required settings, just 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 platform 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 feature
> but only HTTP, it has to include one NULL protocol.
> 

I checked the PciHostBridgeDxe driver to call the EDKII_IOMMU_PROTOCOL, which makes me better understanding your comments. 

  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
    <LibraryClasses>
      ...
      NULL|OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf
  }

So, as you said, it's just the platform behavior so as to hook the platform produces the EDKII_IOMMU_PROTOCOL protocol first, then dispatch PciHostBridgeDxe driver. That's good to me.

For HTTPS configuration, the HttpDxe configuration is only happened during 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 optional dependency to wait for the platform DXE driver produces the EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL.

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. Thank you so such.


> 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 solution
> coding, you know we are always thinking from the user's perspective:).
> 
> 
> > >
> > > If you really think that HttpDxe should only care about these two items
> > > (CA cert and cipher list), then I have another question: do you think it
> > > makes sense to introduce another non-volatile UEFI variable, for the
> > > 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., the
> > 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 before
> > 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 OpenSSL 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
> 
> 


Thanks,
Jiaxin

Re: setting the TLS cipher list for HTTPS booting

[Wu, Jiaxin]

Hi Laszlo,

After the discussion with team member, we still prefer to use the PCD solution. 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.  

Thanks,
Jiaxin

> -----Original Message-----
> From: Wu, Jiaxin
> Sent: Wednesday, January 24, 2018 11:40 AM
> To: Wu, Jiaxin <jiaxin.wu@intel.com>; Laszlo Ersek <lersek@redhat.com>; Fu,
> Siyuan <siyuan.fu@intel.com>; Ye, Ting <ting.ye@intel.com>; Long, Qin
> <qin.long@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>; Hsiung, Harry L
> <harry.l.hsiung@intel.com>
> Cc: edk2-devel-01 <edk2-devel@lists.01.org>
> Subject: RE: setting the TLS cipher list for HTTPS booting
> 
> Hi Laszlo,
> 
> More comments:
> 
> >
> > Dynamic PCDs is just one of the solutions for the required settings, just 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 platform
> 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 feature
> > but only HTTP, it has to include one NULL protocol.
> >
> 
> I checked the PciHostBridgeDxe driver to call the EDKII_IOMMU_PROTOCOL,
> which makes me better understanding your comments.
> 
>   MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
>     <LibraryClasses>
>       ...
>       NULL|OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf
>   }
> 
> So, as you said, it's just the platform behavior so as to hook the platform
> produces the EDKII_IOMMU_PROTOCOL protocol first, then dispatch
> PciHostBridgeDxe driver. That's good to me.
> 
> For HTTPS configuration, the HttpDxe configuration is only happened during 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 optional
> dependency to wait for the platform DXE driver produces the
> EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL.
> 
> 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. Thank you
> so such.
> 
> 
> > 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 solution
> > coding, you know we are always thinking from the user's perspective:).
> >
> >
> > > >
> > > > If you really think that HttpDxe should only care about these two items
> > > > (CA cert and cipher list), then I have another question: do you think it
> > > > makes sense to introduce another non-volatile UEFI variable, for the
> > > > 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., the
> > > 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 before
> > > 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 OpenSSL 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
> >
> >
> 
> 
> Thanks,
> Jiaxin

Re: setting the TLS cipher list for HTTPS booting

[Laszlo Ersek]

On 01/24/18 07:50, Wu, Jiaxin wrote:
> Hi Laszlo,
> 
> After the discussion with team member, we still prefer to use the PCD
> solution. 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.
Ah, I totally missed that NetworkPkg/HttpDxe was a UEFI_DRIVER! :)

In that case, I think *neither* the LocateProtocol() call for an
edk2-specific protocol, *nor* a PcdGetPtr() call are appropriate.
UEFI_DRIVER modules should preferably only use facilities from the UEFI
spec, and the protocol for the dynamic PCDs comes from the PI spec, not
the UEFI spec.

(This would be different if HttpDxe was a DXE_DRIVER -- in that case
both approaches would be valid. I assumed HttpDxe was a DXE_DRIVER, not
sure why.)

(1) So, given that HttpDxe is a UEFI_DRIVER, I think the right approach
would be -- which I believe I also mentioned earlier -- to introduce
another UEFI variable for the list of cipher suites, similarly to
"TlsCaCertificate" (in a custom variable namespace GUID). This would
stay within the framework of the UEFI spec.


(2) Regarding the order between setting these UEFI variables in OVMF,
and consuming them in HttpDxe, I think your argument is good. We can set
the variables in some platform code (DXE_DRIVER) in OVMF, before
End-of-DXE, and HttpDxe will only read them later in BDS.

"OvmfPkg/PlatformDxe" seems like a good candidate for setting these
variables (both considering PlatformDxe's purpose, and because it
already depends on "gEfiVariableWriteArchProtocolGuid").


(3) Regardig the format (EFI_TLS_CIPHER): I agree with you. It seems we
can modify the host environment to pass QEMU (and OVMF) a cipher list
that is already in EFI_TLS_CIPHER format.


So I think the only remaining question is if you like a new UEFI
variable instead of the dynamic PCD, for the cipher list.

Thanks!
Laszlo



> 
> Thanks,
> Jiaxin
> 
>> -----Original Message-----
>> From: Wu, Jiaxin
>> Sent: Wednesday, January 24, 2018 11:40 AM
>> To: Wu, Jiaxin <jiaxin.wu@intel.com>; Laszlo Ersek <lersek@redhat.com>; Fu,
>> Siyuan <siyuan.fu@intel.com>; Ye, Ting <ting.ye@intel.com>; Long, Qin
>> <qin.long@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>; Hsiung, Harry L
>> <harry.l.hsiung@intel.com>
>> Cc: edk2-devel-01 <edk2-devel@lists.01.org>
>> Subject: RE: setting the TLS cipher list for HTTPS booting
>>
>> Hi Laszlo,
>>
>> More comments:
>>
>>>
>>> Dynamic PCDs is just one of the solutions for the required settings, just 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 platform
>> 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 feature
>>> but only HTTP, it has to include one NULL protocol.
>>>
>>
>> I checked the PciHostBridgeDxe driver to call the EDKII_IOMMU_PROTOCOL,
>> which makes me better understanding your comments.
>>
>>   MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
>>     <LibraryClasses>
>>       ...
>>       NULL|OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf
>>   }
>>
>> So, as you said, it's just the platform behavior so as to hook the platform
>> produces the EDKII_IOMMU_PROTOCOL protocol first, then dispatch
>> PciHostBridgeDxe driver. That's good to me.
>>
>> For HTTPS configuration, the HttpDxe configuration is only happened during 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 optional
>> dependency to wait for the platform DXE driver produces the
>> EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL.
>>
>> 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. Thank you
>> so such.
>>
>>
>>> 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 solution
>>> coding, you know we are always thinking from the user's perspective:).
>>>
>>>
>>>>>
>>>>> If you really think that HttpDxe should only care about these two items
>>>>> (CA cert and cipher list), then I have another question: do you think it
>>>>> makes sense to introduce another non-volatile UEFI variable, for the
>>>>> 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., the
>>>> 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 before
>>>> 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 OpenSSL 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
>>>
>>>
>>
>>
>> Thanks,
>> Jiaxin
> 

Re: setting the TLS cipher list for HTTPS booting

[Wu, Jiaxin]

Hi Laszlo,

The HttpDxe driver needs to install the Driver Binding Protocol so as to check if a specific controller is supported by HttpDxe. HttpDxe can only be started if the TcpServiceBindingProtocol existed. So, it has to follow the UEFI Driver Model. 

For the PCD usage, I think it should be fine to cover the configuration of UEFI Drivers through the PCD settings. The requirement of *.inf needs to include the PcdLib and the section of [Pcd]. We already have the similar pattern for this usage, for example, Ps2KeyboardDxe, PciBusDxe, PciSioSerialDxe, and etc in MdeModulePkg. Besides, there are some advantages by using PCD compared to the variable. First, PCD is one kind of interface that more formal than a private variable, the setting by PCD is more acceptable by the consumer. Secondly, from a *security* standpoint, variable can be dumped easily from the flash region. Here, even though it's no security impact towards the cipher list storage because it will be public shared to remote server, but we need to think and *align* with other configurations for TLS in HTTPS level. For example, in the future, we might support the HTTPS mutual authentication, than the host PrivateKey/Password (EfiTlsConfigDataTypeHostPrivateKey) *mustn't* be saved as a variable due to its confidentiality, while PCD is good choice. At that time, we will also provide the PCD for EfiTlsConfigDataTypeCACertificate, which is currently setting by the variable (TlsCaCertificate), so as to align all the configuration setting on one line, which can reduce the complexity of platform usage. Finally, we can also save the variable space.

From the above, the dynamic PCD is a solution I still preferred.

Thanks,
Jiaxin



> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Thursday, January 25, 2018 12:13 AM
> To: Wu, Jiaxin <jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Ye,
> Ting <ting.ye@intel.com>; Long, Qin <qin.long@intel.com>; Yao, Jiewen
> <jiewen.yao@intel.com>; Hsiung, Harry L <harry.l.hsiung@intel.com>
> Cc: edk2-devel-01 <edk2-devel@lists.01.org>
> Subject: Re: setting the TLS cipher list for HTTPS booting
> 
> On 01/24/18 07:50, Wu, Jiaxin wrote:
> > Hi Laszlo,
> >
> > After the discussion with team member, we still prefer to use the PCD
> > solution. 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.
> Ah, I totally missed that NetworkPkg/HttpDxe was a UEFI_DRIVER! :)
> 
> In that case, I think *neither* the LocateProtocol() call for an
> edk2-specific protocol, *nor* a PcdGetPtr() call are appropriate.
> UEFI_DRIVER modules should preferably only use facilities from the UEFI
> spec, and the protocol for the dynamic PCDs comes from the PI spec, not
> the UEFI spec.
> 
> (This would be different if HttpDxe was a DXE_DRIVER -- in that case
> both approaches would be valid. I assumed HttpDxe was a DXE_DRIVER, not
> sure why.)
> 
> (1) So, given that HttpDxe is a UEFI_DRIVER, I think the right approach
> would be -- which I believe I also mentioned earlier -- to introduce
> another UEFI variable for the list of cipher suites, similarly to
> "TlsCaCertificate" (in a custom variable namespace GUID). This would
> stay within the framework of the UEFI spec.
> 
> 
> (2) Regarding the order between setting these UEFI variables in OVMF,
> and consuming them in HttpDxe, I think your argument is good. We can set
> the variables in some platform code (DXE_DRIVER) in OVMF, before
> End-of-DXE, and HttpDxe will only read them later in BDS.
> 
> "OvmfPkg/PlatformDxe" seems like a good candidate for setting these
> variables (both considering PlatformDxe's purpose, and because it
> already depends on "gEfiVariableWriteArchProtocolGuid").
> 
> 
> (3) Regardig the format (EFI_TLS_CIPHER): I agree with you. It seems we
> can modify the host environment to pass QEMU (and OVMF) a cipher list
> that is already in EFI_TLS_CIPHER format.
> 
> 
> So I think the only remaining question is if you like a new UEFI
> variable instead of the dynamic PCD, for the cipher list.
> 
> Thanks!
> Laszlo
> 
> 
> 
> >
> > Thanks,
> > Jiaxin
> >
> >> -----Original Message-----
> >> From: Wu, Jiaxin
> >> Sent: Wednesday, January 24, 2018 11:40 AM
> >> To: Wu, Jiaxin <jiaxin.wu@intel.com>; Laszlo Ersek <lersek@redhat.com>;
> Fu,
> >> Siyuan <siyuan.fu@intel.com>; Ye, Ting <ting.ye@intel.com>; Long, Qin
> >> <qin.long@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>; Hsiung, Harry
> L
> >> <harry.l.hsiung@intel.com>
> >> Cc: edk2-devel-01 <edk2-devel@lists.01.org>
> >> Subject: RE: setting the TLS cipher list for HTTPS booting
> >>
> >> Hi Laszlo,
> >>
> >> More comments:
> >>
> >>>
> >>> Dynamic PCDs is just one of the solutions for the required settings, just 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 platform
> >> 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
> feature
> >>> but only HTTP, it has to include one NULL protocol.
> >>>
> >>
> >> I checked the PciHostBridgeDxe driver to call the EDKII_IOMMU_PROTOCOL,
> >> which makes me better understanding your comments.
> >>
> >>   MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
> >>     <LibraryClasses>
> >>       ...
> >>
> NULL|OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf
> >>   }
> >>
> >> So, as you said, it's just the platform behavior so as to hook the platform
> >> produces the EDKII_IOMMU_PROTOCOL protocol first, then dispatch
> >> PciHostBridgeDxe driver. That's good to me.
> >>
> >> For HTTPS configuration, the HttpDxe configuration is only happened during
> 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 optional
> >> dependency to wait for the platform DXE driver produces the
> >> EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL.
> >>
> >> 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. Thank
> you
> >> so such.
> >>
> >>
> >>> 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 solution
> >>> coding, you know we are always thinking from the user's perspective:).
> >>>
> >>>
> >>>>>
> >>>>> If you really think that HttpDxe should only care about these two items
> >>>>> (CA cert and cipher list), then I have another question: do you think it
> >>>>> makes sense to introduce another non-volatile UEFI variable, for the
> >>>>> 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., the
> >>>> 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 before
> >>>> 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 OpenSSL
> 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
> >>>
> >>>
> >>
> >>
> >> Thanks,
> >> Jiaxin
> >

Re: setting the TLS cipher list for HTTPS booting

[Laszlo Ersek]

On 01/25/18 05:52, Wu, Jiaxin wrote:
> Hi Laszlo,
> 
> The HttpDxe driver needs to install the Driver Binding Protocol so as
> to check if a specific controller is supported by HttpDxe. HttpDxe
> can only be started if the TcpServiceBindingProtocol existed. So, it
> has to follow the UEFI Driver Model.
> 
> For the PCD usage, I think it should be fine to cover the
> configuration of UEFI Drivers through the PCD settings. The
> requirement of *.inf needs to include the PcdLib and the section of
> [Pcd]. We already have the similar pattern for this usage, for
> example, Ps2KeyboardDxe, PciBusDxe, PciSioSerialDxe, and etc in
> MdeModulePkg. Besides, there are some advantages by using PCD
> compared to the variable. First, PCD is one kind of interface that
> more formal than a private variable, the setting by PCD is more
> acceptable by the consumer. Secondly, from a *security* standpoint,
> variable can be dumped easily from the flash region. Here, even
> though it's no security impact towards the cipher list storage
> because it will be public shared to remote server, but we need to
> think and *align* with other configurations for TLS in HTTPS level.
> For example, in the future, we might support the HTTPS mutual
> authentication, than the host PrivateKey/Password
> (EfiTlsConfigDataTypeHostPrivateKey) *mustn't* be saved as a variable
> due to its confidentiality, while PCD is good choice. At that time,
> we will also provide the PCD for EfiTlsConfigDataTypeCACertificate,
> which is currently setting by the variable (TlsCaCertificate), so as
> to align all the configuration setting on one line, which can reduce
> the complexity of platform usage. Finally, we can also save the
> variable space.
> 
> From the above, the dynamic PCD is a solution I still preferred.

OK, it works for me. Thanks!
Laszlo

Re: setting the TLS cipher list for HTTPS booting

[Wu, Jiaxin]

Hi Laszlo,

In recent days, we received the comment from Kinney about the PCD usage in UEFI driver.  Kinney doesn't recommend us to use the *dynamic PCD* in *soft-loading* UEFI driver even though it's not prohibited. 

So, we want to confirm with you whether this is the urgent request need us to support it ASAP or it's in low priority. 
If you need us support the feature ASAP, we can use the  private variable solution as we discussed before since there is no security issue and the size requirement is not big.  
If not urgency, we might consider whether need to define a platform to driver configuration protocol or not. You know it will take a long time to scandalize one protocol for platform HTTPS configuration in the future UEFI spec.

Thanks,
Jiaxin


> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Thursday, January 25, 2018 8:42 PM
> To: Wu, Jiaxin <jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Ye,
> Ting <ting.ye@intel.com>; Long, Qin <qin.long@intel.com>; Yao, Jiewen
> <jiewen.yao@intel.com>; Hsiung, Harry L <harry.l.hsiung@intel.com>
> Cc: edk2-devel-01 <edk2-devel@lists.01.org>
> Subject: Re: setting the TLS cipher list for HTTPS booting
> 
> On 01/25/18 05:52, Wu, Jiaxin wrote:
> > Hi Laszlo,
> >
> > The HttpDxe driver needs to install the Driver Binding Protocol so as
> > to check if a specific controller is supported by HttpDxe. HttpDxe
> > can only be started if the TcpServiceBindingProtocol existed. So, it
> > has to follow the UEFI Driver Model.
> >
> > For the PCD usage, I think it should be fine to cover the
> > configuration of UEFI Drivers through the PCD settings. The
> > requirement of *.inf needs to include the PcdLib and the section of
> > [Pcd]. We already have the similar pattern for this usage, for
> > example, Ps2KeyboardDxe, PciBusDxe, PciSioSerialDxe, and etc in
> > MdeModulePkg. Besides, there are some advantages by using PCD
> > compared to the variable. First, PCD is one kind of interface that
> > more formal than a private variable, the setting by PCD is more
> > acceptable by the consumer. Secondly, from a *security* standpoint,
> > variable can be dumped easily from the flash region. Here, even
> > though it's no security impact towards the cipher list storage
> > because it will be public shared to remote server, but we need to
> > think and *align* with other configurations for TLS in HTTPS level.
> > For example, in the future, we might support the HTTPS mutual
> > authentication, than the host PrivateKey/Password
> > (EfiTlsConfigDataTypeHostPrivateKey) *mustn't* be saved as a variable
> > due to its confidentiality, while PCD is good choice. At that time,
> > we will also provide the PCD for EfiTlsConfigDataTypeCACertificate,
> > which is currently setting by the variable (TlsCaCertificate), so as
> > to align all the configuration setting on one line, which can reduce
> > the complexity of platform usage. Finally, we can also save the
> > variable space.
> >
> > From the above, the dynamic PCD is a solution I still preferred.
> 
> OK, it works for me. Thanks!
> Laszlo

Re: setting the TLS cipher list for HTTPS booting

[Laszlo Ersek]

On 02/05/18 04:33, Wu, Jiaxin wrote:
> Hi Laszlo,
>
> In recent days, we received the comment from Kinney about the PCD
> usage in UEFI driver.  Kinney doesn't recommend us to use the *dynamic
> PCD* in *soft-loading* UEFI driver even though it's not prohibited.
>
> So, we want to confirm with you whether this is the urgent request
> need us to support it ASAP or it's in low priority.
>
> If you need us support the feature ASAP, we can use the  private
> variable solution as we discussed before since there is no security
> issue and the size requirement is not big.
>
> If not urgency, we might consider whether need to define a platform to
> driver configuration protocol or not. You know it will take a long
> time to scandalize one protocol for platform HTTPS configuration in
> the future UEFI spec.

The variable approach sounds good to me, but with a small twist:

Could we please leave it up to the platform whether the private variable
is non-volatile versus volatile? Because platform X might want to
configure the cipher suite list once, permanently, while platform Y
might want to configure the cipher suite list dynamically on each boot.
For platform Y, spending any flash space (and flash writing time) on the
variable is superfluous.

For QEMU / OVMF specifically, I would prefer a volatile, boot-time only
variable. After setting this variable, I think OVMF platform code should
even lock it down with the edk2 variable lock protocol. In effect this
would behave like a "read only" PCD -- no flash impact at all.

As long as HttpDxe only calls gRT->GetVariable() (or equivalent wrappers
from UefiLib) on the new variable, the variable's attributes should not
matter; they can be left to the platform.

Thanks!
Laszlo


>> -----Original Message-----
>> From: Laszlo Ersek [mailto:lersek@redhat.com]
>> Sent: Thursday, January 25, 2018 8:42 PM
>> To: Wu, Jiaxin <jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Ye,
>> Ting <ting.ye@intel.com>; Long, Qin <qin.long@intel.com>; Yao, Jiewen
>> <jiewen.yao@intel.com>; Hsiung, Harry L <harry.l.hsiung@intel.com>
>> Cc: edk2-devel-01 <edk2-devel@lists.01.org>
>> Subject: Re: setting the TLS cipher list for HTTPS booting
>>
>> On 01/25/18 05:52, Wu, Jiaxin wrote:
>>> Hi Laszlo,
>>>
>>> The HttpDxe driver needs to install the Driver Binding Protocol so as
>>> to check if a specific controller is supported by HttpDxe. HttpDxe
>>> can only be started if the TcpServiceBindingProtocol existed. So, it
>>> has to follow the UEFI Driver Model.
>>>
>>> For the PCD usage, I think it should be fine to cover the
>>> configuration of UEFI Drivers through the PCD settings. The
>>> requirement of *.inf needs to include the PcdLib and the section of
>>> [Pcd]. We already have the similar pattern for this usage, for
>>> example, Ps2KeyboardDxe, PciBusDxe, PciSioSerialDxe, and etc in
>>> MdeModulePkg. Besides, there are some advantages by using PCD
>>> compared to the variable. First, PCD is one kind of interface that
>>> more formal than a private variable, the setting by PCD is more
>>> acceptable by the consumer. Secondly, from a *security* standpoint,
>>> variable can be dumped easily from the flash region. Here, even
>>> though it's no security impact towards the cipher list storage
>>> because it will be public shared to remote server, but we need to
>>> think and *align* with other configurations for TLS in HTTPS level.
>>> For example, in the future, we might support the HTTPS mutual
>>> authentication, than the host PrivateKey/Password
>>> (EfiTlsConfigDataTypeHostPrivateKey) *mustn't* be saved as a variable
>>> due to its confidentiality, while PCD is good choice. At that time,
>>> we will also provide the PCD for EfiTlsConfigDataTypeCACertificate,
>>> which is currently setting by the variable (TlsCaCertificate), so as
>>> to align all the configuration setting on one line, which can reduce
>>> the complexity of platform usage. Finally, we can also save the
>>> variable space.
>>>
>>> From the above, the dynamic PCD is a solution I still preferred.
>>
>> OK, it works for me. Thanks!
>> Laszlo

Re: setting the TLS cipher list for HTTPS booting

[Wu, Jiaxin]

Leaving the variable up to the platform setting is good to me. 

Mike,

If you have no comments, we will follow the variable solution. 

Thanks,
Jiaxin

> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Monday, February 5, 2018 6:47 PM
> To: Wu, Jiaxin <jiaxin.wu@intel.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Ye, Ting
> <ting.ye@intel.com>; Li, Ruth <ruth.li@intel.com>; Long, Qin
> <qin.long@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>; Hsiung, Harry L
> <harry.l.hsiung@intel.com>
> Cc: edk2-devel-01 <edk2-devel@lists.01.org>
> Subject: Re: setting the TLS cipher list for HTTPS booting
> 
> On 02/05/18 04:33, Wu, Jiaxin wrote:
> > Hi Laszlo,
> >
> > In recent days, we received the comment from Kinney about the PCD
> > usage in UEFI driver.  Kinney doesn't recommend us to use the *dynamic
> > PCD* in *soft-loading* UEFI driver even though it's not prohibited.
> >
> > So, we want to confirm with you whether this is the urgent request
> > need us to support it ASAP or it's in low priority.
> >
> > If you need us support the feature ASAP, we can use the  private
> > variable solution as we discussed before since there is no security
> > issue and the size requirement is not big.
> >
> > If not urgency, we might consider whether need to define a platform to
> > driver configuration protocol or not. You know it will take a long
> > time to scandalize one protocol for platform HTTPS configuration in
> > the future UEFI spec.
> 
> The variable approach sounds good to me, but with a small twist:
> 
> Could we please leave it up to the platform whether the private variable
> is non-volatile versus volatile? Because platform X might want to
> configure the cipher suite list once, permanently, while platform Y
> might want to configure the cipher suite list dynamically on each boot.
> For platform Y, spending any flash space (and flash writing time) on the
> variable is superfluous.
> 
> For QEMU / OVMF specifically, I would prefer a volatile, boot-time only
> variable. After setting this variable, I think OVMF platform code should
> even lock it down with the edk2 variable lock protocol. In effect this
> would behave like a "read only" PCD -- no flash impact at all.
> 
> As long as HttpDxe only calls gRT->GetVariable() (or equivalent wrappers
> from UefiLib) on the new variable, the variable's attributes should not
> matter; they can be left to the platform.
> 
> Thanks!
> Laszlo
> 
> 
> >> -----Original Message-----
> >> From: Laszlo Ersek [mailto:lersek@redhat.com]
> >> Sent: Thursday, January 25, 2018 8:42 PM
> >> To: Wu, Jiaxin <jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>;
> Ye,
> >> Ting <ting.ye@intel.com>; Long, Qin <qin.long@intel.com>; Yao, Jiewen
> >> <jiewen.yao@intel.com>; Hsiung, Harry L <harry.l.hsiung@intel.com>
> >> Cc: edk2-devel-01 <edk2-devel@lists.01.org>
> >> Subject: Re: setting the TLS cipher list for HTTPS booting
> >>
> >> On 01/25/18 05:52, Wu, Jiaxin wrote:
> >>> Hi Laszlo,
> >>>
> >>> The HttpDxe driver needs to install the Driver Binding Protocol so as
> >>> to check if a specific controller is supported by HttpDxe. HttpDxe
> >>> can only be started if the TcpServiceBindingProtocol existed. So, it
> >>> has to follow the UEFI Driver Model.
> >>>
> >>> For the PCD usage, I think it should be fine to cover the
> >>> configuration of UEFI Drivers through the PCD settings. The
> >>> requirement of *.inf needs to include the PcdLib and the section of
> >>> [Pcd]. We already have the similar pattern for this usage, for
> >>> example, Ps2KeyboardDxe, PciBusDxe, PciSioSerialDxe, and etc in
> >>> MdeModulePkg. Besides, there are some advantages by using PCD
> >>> compared to the variable. First, PCD is one kind of interface that
> >>> more formal than a private variable, the setting by PCD is more
> >>> acceptable by the consumer. Secondly, from a *security* standpoint,
> >>> variable can be dumped easily from the flash region. Here, even
> >>> though it's no security impact towards the cipher list storage
> >>> because it will be public shared to remote server, but we need to
> >>> think and *align* with other configurations for TLS in HTTPS level.
> >>> For example, in the future, we might support the HTTPS mutual
> >>> authentication, than the host PrivateKey/Password
> >>> (EfiTlsConfigDataTypeHostPrivateKey) *mustn't* be saved as a variable
> >>> due to its confidentiality, while PCD is good choice. At that time,
> >>> we will also provide the PCD for EfiTlsConfigDataTypeCACertificate,
> >>> which is currently setting by the variable (TlsCaCertificate), so as
> >>> to align all the configuration setting on one line, which can reduce
> >>> the complexity of platform usage. Finally, we can also save the
> >>> variable space.
> >>>
> >>> From the above, the dynamic PCD is a solution I still preferred.
> >>
> >> OK, it works for me. Thanks!
> >> Laszlo