doc: announce cryptodev changes to offload RSA in VirtIO

Message ID 20240722145551.1159-1-gmuthukrishn@marvell.com (mailing list archive)
State Accepted, archived
Delegated to: Thomas Monjalon
Headers
Series doc: announce cryptodev changes to offload RSA in VirtIO |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/loongarch-compilation success Compilation OK
ci/loongarch-unit-testing success Unit Testing PASS
ci/Intel-compilation success Compilation OK
ci/github-robot: build success github build: passed
ci/intel-Testing success Testing PASS
ci/intel-Functional success Functional PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-marvell-Functional success Functional Testing PASS
ci/iol-broadcom-Performance success Performance Testing PASS
ci/iol-abi-testing success Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-broadcom-Functional success Functional Testing PASS
ci/iol-compile-arm64-testing success Testing PASS
ci/iol-unit-arm64-testing success Testing PASS
ci/iol-unit-amd64-testing success Testing PASS
ci/iol-compile-amd64-testing success Testing PASS
ci/iol-sample-apps-testing success Testing PASS

Commit Message

Gowrishankar Muthukrishnan July 22, 2024, 2:55 p.m. UTC
Announce cryptodev changes to offload RSA asymmetric operation in
VirtIO PMD.

Signed-off-by: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
--
RFC:
  https://patches.dpdk.org/project/dpdk/patch/20230928095300.1353-2-gmuthukrishn@marvell.com/
  https://patches.dpdk.org/project/dpdk/patch/20230928095300.1353-3-gmuthukrishn@marvell.com/
---
 doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
 1 file changed, 11 insertions(+)
  

Comments

Anoob Joseph July 24, 2024, 5:10 a.m. UTC | #1
> Subject: [PATCH] doc: announce cryptodev changes to offload RSA in VirtIO
> 
> Announce cryptodev changes to offload RSA asymmetric operation in VirtIO
> PMD.
> 
> Signed-off-by: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>

Acked-by: Anoob Joseph <anoobj@marvell.com>
  
Akhil Goyal July 24, 2024, 6:49 a.m. UTC | #2
> Announce cryptodev changes to offload RSA asymmetric operation in
> VirtIO PMD.
> 
> Signed-off-by: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
> --
> RFC:
>   https://patches.dpdk.org/project/dpdk/patch/20230928095300.1353-2-gmuthukrishn@marvell.com/
>   https://patches.dpdk.org/project/dpdk/patch/20230928095300.1353-3-gmuthukrishn@marvell.com/
> ---
Acked-by: Akhil Goyal <gakhil@marvell.com>

>  doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 6948641ff6..26fec84aba 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -147,3 +147,14 @@ Deprecation Notices
>    will be deprecated and subsequently removed in DPDK 24.11 release.
>    Before this, the new port library API (functions rte_swx_port_*)
>    will gradually transition from experimental to stable status.
> +
> +* cryptodev: The struct rte_crypto_rsa_padding will be moved from
> +  rte_crypto_rsa_op_param struct to rte_crypto_rsa_xform struct,
> +  breaking ABI. The new location is recommended to comply with
> +  virtio-crypto specification. Applications and drivers using
> +  this struct will be updated.
> +
> +* cryptodev: The rte_crypto_rsa_xform struct member to hold private key
> +  in either exponent or quintuple format is changed from union to struct
> +  data type. This change is to support ASN.1 syntax (RFC 3447 Appendix A.1.2).
> +  This change will not break existing applications.
> --
> 2.21.0
  
Arkadiusz Kusztal July 25, 2024, 9:48 a.m. UTC | #3
Hi Gowrishankar,

> -----Original Message-----
> From: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
> Sent: Monday, July 22, 2024 4:56 PM
> To: dev@dpdk.org; Anoob Joseph <anoobj@marvell.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; ciara.power@intel.com; jerinj@marvell.com;
> fanzhang.oss@gmail.com; Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>;
> Ji, Kai <kai.ji@intel.com>; jack.bond-preston@foss.arm.com; Marchand, David
> <david.marchand@redhat.com>; hemant.agrawal@nxp.com; De Lara Guarch,
> Pablo <pablo.de.lara.guarch@intel.com>; Trahe, Fiona
> <fiona.trahe@intel.com>; Doherty, Declan <declan.doherty@intel.com>;
> matan@nvidia.com; ruifeng.wang@arm.com; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>; maxime.coquelin@redhat.com;
> chenbox@nvidia.com; sunilprakashrao.uttarwar@amd.com;
> andrew.boyer@amd.com; ajit.khaparde@broadcom.com;
> raveendra.padasalagi@broadcom.com; vikas.gupta@broadcom.com;
> zhangfei.gao@linaro.org; g.singh@nxp.com; jianjay.zhou@huawei.com; Daly,
> Lee <lee.daly@intel.com>
> Cc: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
> Subject: [PATCH] doc: announce cryptodev changes to offload RSA in VirtIO
> 
> Announce cryptodev changes to offload RSA asymmetric operation in VirtIO
> PMD.
> 
> Signed-off-by: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
> --
> RFC:
>   https://patches.dpdk.org/project/dpdk/patch/20230928095300.1353-2-
> gmuthukrishn@marvell.com/
>   https://patches.dpdk.org/project/dpdk/patch/20230928095300.1353-3-
> gmuthukrishn@marvell.com/
> ---
>  doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 6948641ff6..26fec84aba 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -147,3 +147,14 @@ Deprecation Notices
>    will be deprecated and subsequently removed in DPDK 24.11 release.
>    Before this, the new port library API (functions rte_swx_port_*)
>    will gradually transition from experimental to stable status.
> +
> +* cryptodev: The struct rte_crypto_rsa_padding will be moved from
> +  rte_crypto_rsa_op_param struct to rte_crypto_rsa_xform struct,
> +  breaking ABI. The new location is recommended to comply with
> +  virtio-crypto specification. Applications and drivers using
> +  this struct will be updated.
> +

The problem here, I see is that there is one private key but multiple combinations of padding.
Therefore, for every padding variation, we need to copy the same private key anew, duplicating it in memory.
The only reason for me to keep a session-like struct in asymmetric crypto was exactly this.

> +* cryptodev: The rte_crypto_rsa_xform struct member to hold private key
> +  in either exponent or quintuple format is changed from union to
> +struct
> +  data type. This change is to support ASN.1 syntax (RFC 3447 Appendix A.1.2).
> +  This change will not break existing applications.
This one I agree. RFC 8017 obsoletes RFC 3447.
> --
> 2.21.0
  
Gowrishankar Muthukrishnan July 25, 2024, 3:53 p.m. UTC | #4
> +* cryptodev: The struct rte_crypto_rsa_padding will be moved from

> +  rte_crypto_rsa_op_param struct to rte_crypto_rsa_xform struct,

> +  breaking ABI. The new location is recommended to comply with

> +  virtio-crypto specification. Applications and drivers using

> +  this struct will be updated.

> +



The problem here, I see is that there is one private key but multiple combinations of padding.

Therefore, for every padding variation, we need to copy the same private key anew, duplicating it in memory.

The only reason for me to keep a session-like struct in asymmetric crypto was exactly this.



Each padding scheme in RSA has its own pros and cons (in terms of implementations as well).

When we share the same private key for Sign (and its public key in case of Encryption) between

multiple crypto ops (varying by padding schemes among cops), a vulnerable attack against one scheme

could potentially open door to used private key in the session and hence take advantage

on other crypto operations.



I think, this could be one reason for why VirtIO spec mandates padding info as session parameter.

Hence, more than duplicating in memory, private and public keys are secured and in catastrophe,

only that session could be destroyed.



Thanks,

Gowrishankar



Though padding schemes could be same



> +* cryptodev: The rte_crypto_rsa_xform struct member to hold private key

> +  in either exponent or quintuple format is changed from union to

> +struct

> +  data type. This change is to support ASN.1 syntax (RFC 3447 Appendix A.1.2).

> +  This change will not break existing applications.

This one I agree. RFC 8017 obsoletes RFC 3447.



Thanks,

Gowrishankar

> --

> 2.21.0
  
Gowrishankar Muthukrishnan July 25, 2024, 4 p.m. UTC | #5
Hi ArkadiuszX,


> +

> +* cryptodev: The struct rte_crypto_rsa_padding will be moved from

> +  rte_crypto_rsa_op_param struct to rte_crypto_rsa_xform struct,

> +  breaking ABI. The new location is recommended to comply with

> +  virtio-crypto specification. Applications and drivers using

> +  this struct will be updated.

> +



The problem here, I see is that there is one private key but multiple combinations of padding.

Therefore, for every padding variation, we need to copy the same private key anew, duplicating it in memory.

The only reason for me to keep a session-like struct in asymmetric crypto was exactly this.





Each padding scheme in RSA has its own pros and cons (in terms of implementations as well).

When we share the same private key for Sign (and its public key in case of Encryption) between

multiple crypto ops (varying by padding schemes among cops), a vulnerable attack against one scheme

could potentially open door to used private key in the session and hence take advantage

on other crypto operations.



I think, this could be one reason for why VirtIO spec mandates padding info as session parameter.

Hence, more than duplicating in memory, private and public keys are secured and in catastrophe,

only that session could be destroyed.



Please share your thoughts.



> +* cryptodev: The rte_crypto_rsa_xform struct member to hold private key

> +  in either exponent or quintuple format is changed from union to

> +struct

> +  data type. This change is to support ASN.1 syntax (RFC 3447 Appendix A.1.2).

> +  This change will not break existing applications.

This one I agree. RFC 8017 obsoletes RFC 3447.



Thanks,

Gowrishankar



> --

> 2.21.0
  
Gowrishankar Muthukrishnan July 30, 2024, 2:39 p.m. UTC | #6
Hi,
We need to fix padding info in DPDK as per VirtIO specification in order to support RSA in virtio devices. VirtIO-crypto specification and DPDK specification differs in the way padding is handled.
With current DPDK & virtio specification, it is impossible to support RSA in virtio-crypto. If you think DPDK spec should not be modified, we will try to amend the virtIO spec to match DPDK, but since we do not know if the virtIO community would accept, can we merge the deprecation notice?

Thanks,
Gowrishankar

ZjQcmQRYFpfptBannerEnd

>>> +* cryptodev: The struct rte_crypto_rsa_padding will be moved from

>>> +  rte_crypto_rsa_op_param struct to rte_crypto_rsa_xform struct,

>>> +  breaking ABI. The new location is recommended to comply with

>>> +  virtio-crypto specification. Applications and drivers using

>>> +  this struct will be updated.

>>> +



>> The problem here, I see is that there is one private key but multiple combinations of padding.

>> Therefore, for every padding variation, we need to copy the same private key anew, duplicating it in memory.

>> The only reason for me to keep a session-like struct in asymmetric crypto was exactly this.



> Each padding scheme in RSA has its own pros and cons (in terms of implementations as well).

> When we share the same private key for Sign (and its public key in case of Encryption) between

> multiple crypto ops (varying by padding schemes among cops), a vulnerable attack against one scheme

> could potentially open door to used private key in the session and hence take advantage

> on other crypto operations.



> I think, this could be one reason for why VirtIO spec mandates padding info as session parameter.

> Hence, more than duplicating in memory, private and public keys are secured and in catastrophe,

> only that session could be destroyed.



>>> +* cryptodev: The rte_crypto_rsa_xform struct member to hold private key

>>> +  in either exponent or quintuple format is changed from union to

>>> +struct

>>> +  data type. This change is to support ASN.1 syntax (RFC 3447 Appendix A.1.2).

>>> +  This change will not break existing applications.

>>This one I agree. RFC 8017 obsoletes RFC 3447.



> Thanks,

> Gowrishankar
  
Thomas Monjalon July 31, 2024, 12:51 p.m. UTC | #7
30/07/2024 16:39, Gowrishankar Muthukrishnan:
> Hi,
> We need to fix padding info in DPDK as per VirtIO specification in order to support RSA in virtio devices. VirtIO-crypto specification and DPDK specification differs in the way padding is handled.
> With current DPDK & virtio specification, it is impossible to support RSA in virtio-crypto. If you think DPDK spec should not be modified, we will try to amend the virtIO spec to match DPDK, but since we do not know if the virtIO community would accept, can we merge the deprecation notice?

There is a long list of Cc but I see no support outside of Marvell.



> >>> +* cryptodev: The struct rte_crypto_rsa_padding will be moved from
> >>> +  rte_crypto_rsa_op_param struct to rte_crypto_rsa_xform struct,
> >>> +  breaking ABI. The new location is recommended to comply with
> >>> +  virtio-crypto specification. Applications and drivers using
> >>> +  this struct will be updated.
> >>> +
> 
> 
> >> The problem here, I see is that there is one private key but multiple combinations of padding.
> >> Therefore, for every padding variation, we need to copy the same private key anew, duplicating it in memory.
> >> The only reason for me to keep a session-like struct in asymmetric crypto was exactly this.
> > 
> > Each padding scheme in RSA has its own pros and cons (in terms of implementations as well).
> > When we share the same private key for Sign (and its public key in case of Encryption) between
> > multiple crypto ops (varying by padding schemes among cops), a vulnerable attack against one scheme
> > could potentially open door to used private key in the session and hence take advantage
> > on other crypto operations.
> > 
> > I think, this could be one reason for why VirtIO spec mandates padding info as session parameter.
> > Hence, more than duplicating in memory, private and public keys are secured and in catastrophe,
> > only that session could be destroyed.
> 
> 
> >>> +* cryptodev: The rte_crypto_rsa_xform struct member to hold private key
> >>> +  in either exponent or quintuple format is changed from union to
> >>> +struct
> >>> +  data type. This change is to support ASN.1 syntax (RFC 3447 Appendix A.1.2).
> >>> +  This change will not break existing applications.
> > >
> > > This one I agree. RFC 8017 obsoletes RFC 3447.
  
Thomas Monjalon July 31, 2024, 2:26 p.m. UTC | #8
I'm not sure why we don't have a consensus on an idea proposed as RFC in September 2023.

Because there is not enough involvement outside of the Marvell team,
I will keep a vague announce for the first item:

cryptodev: Some changes may happen to manage RSA padding for virtio-crypto.

The second item is applied verbatim, thanks.


31/07/2024 14:51, Thomas Monjalon:
> 30/07/2024 16:39, Gowrishankar Muthukrishnan:
> > Hi,
> > We need to fix padding info in DPDK as per VirtIO specification in order to support RSA in virtio devices. VirtIO-crypto specification and DPDK specification differs in the way padding is handled.
> > With current DPDK & virtio specification, it is impossible to support RSA in virtio-crypto. If you think DPDK spec should not be modified, we will try to amend the virtIO spec to match DPDK, but since we do not know if the virtIO community would accept, can we merge the deprecation notice?
> 
> There is a long list of Cc but I see no support outside of Marvell.
> 
> 
> 
> > >>> +* cryptodev: The struct rte_crypto_rsa_padding will be moved from
> > >>> +  rte_crypto_rsa_op_param struct to rte_crypto_rsa_xform struct,
> > >>> +  breaking ABI. The new location is recommended to comply with
> > >>> +  virtio-crypto specification. Applications and drivers using
> > >>> +  this struct will be updated.
> > >>> +
> > 
> > 
> > >> The problem here, I see is that there is one private key but multiple combinations of padding.
> > >> Therefore, for every padding variation, we need to copy the same private key anew, duplicating it in memory.
> > >> The only reason for me to keep a session-like struct in asymmetric crypto was exactly this.
> > > 
> > > Each padding scheme in RSA has its own pros and cons (in terms of implementations as well).
> > > When we share the same private key for Sign (and its public key in case of Encryption) between
> > > multiple crypto ops (varying by padding schemes among cops), a vulnerable attack against one scheme
> > > could potentially open door to used private key in the session and hence take advantage
> > > on other crypto operations.
> > > 
> > > I think, this could be one reason for why VirtIO spec mandates padding info as session parameter.
> > > Hence, more than duplicating in memory, private and public keys are secured and in catastrophe,
> > > only that session could be destroyed.
> > 
> > 
> > >>> +* cryptodev: The rte_crypto_rsa_xform struct member to hold private key
> > >>> +  in either exponent or quintuple format is changed from union to
> > >>> +struct
> > >>> +  data type. This change is to support ASN.1 syntax (RFC 3447 Appendix A.1.2).
> > >>> +  This change will not break existing applications.
> > > >
> > > > This one I agree. RFC 8017 obsoletes RFC 3447.
  
Arkadiusz Kusztal Aug. 7, 2024, 1:31 p.m. UTC | #9
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, July 31, 2024 4:27 PM
> To: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
> Cc: dev@dpdk.org; Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>;
> dev@dpdk.org; Anoob Joseph <anoobj@marvell.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; ciara.power@intel.com; Jerin Jacob
> <jerinj@marvell.com>; fanzhang.oss@gmail.com; Ji, Kai <kai.ji@intel.com>;
> jack.bond-preston@foss.arm.com; Marchand, David
> <david.marchand@redhat.com>; hemant.agrawal@nxp.com; De Lara Guarch,
> Pablo <pablo.de.lara.guarch@intel.com>; Trahe, Fiona
> <fiona.trahe@intel.com>; Doherty, Declan <declan.doherty@intel.com>;
> matan@nvidia.com; ruifeng.wang@arm.com; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>; maxime.coquelin@redhat.com;
> chenbox@nvidia.com; sunilprakashrao.uttarwar@amd.com;
> andrew.boyer@amd.com; ajit.khaparde@broadcom.com;
> raveendra.padasalagi@broadcom.com; vikas.gupta@broadcom.com;
> zhangfei.gao@linaro.org; g.singh@nxp.com; jianjay.zhou@huawei.com; Daly,
> Lee <lee.daly@intel.com>
> Subject: Re: [PATCH] doc: announce cryptodev changes to offload RSA in VirtIO
> 
> I'm not sure why we don't have a consensus on an idea proposed as RFC in
> September 2023.
> 
> Because there is not enough involvement outside of the Marvell team, I will
> keep a vague announce for the first item:
> 
> cryptodev: Some changes may happen to manage RSA padding for virtio-crypto.
> 
> The second item is applied verbatim, thanks.
> 
> 
> 31/07/2024 14:51, Thomas Monjalon:
> > 30/07/2024 16:39, Gowrishankar Muthukrishnan:
> > > Hi,
> > > We need to fix padding info in DPDK as per VirtIO specification in order to
> support RSA in virtio devices. VirtIO-crypto specification and DPDK specification
> differs in the way padding is handled.
> > > With current DPDK & virtio specification, it is impossible to support RSA in
> virtio-crypto. If you think DPDK spec should not be modified, we will try to
> amend the virtIO spec to match DPDK, but since we do not know if the virtIO
> community would accept, can we merge the deprecation notice?
> >
> > There is a long list of Cc but I see no support outside of Marvell.
> >
> >
> >
> > > >>> +* cryptodev: The struct rte_crypto_rsa_padding will be moved
> > > >>> +from
> > > >>> +  rte_crypto_rsa_op_param struct to rte_crypto_rsa_xform
> > > >>> +struct,
> > > >>> +  breaking ABI. The new location is recommended to comply with
> > > >>> +  virtio-crypto specification. Applications and drivers using
> > > >>> +  this struct will be updated.
> > > >>> +
> > >
> > >
> > > >> The problem here, I see is that there is one private key but multiple
> combinations of padding.
> > > >> Therefore, for every padding variation, we need to copy the same private
> key anew, duplicating it in memory.
> > > >> The only reason for me to keep a session-like struct in asymmetric crypto
> was exactly this.
> > > >
> > > > Each padding scheme in RSA has its own pros and cons (in terms of
> implementations as well).
> > > > When we share the same private key for Sign (and its public key in
> > > > case of Encryption) between multiple crypto ops (varying by
> > > > padding schemes among cops), a vulnerable attack against one
> > > > scheme could potentially open door to used private key in the session and
> hence take advantage on other crypto operations.
> > > >
> > > > I think, this could be one reason for why VirtIO spec mandates padding info
> as session parameter.
> > > > Hence, more than duplicating in memory, private and public keys
> > > > are secured and in catastrophe, only that session could be destroyed.

Hi Gowrishankar,

Sorry for the delayed response.

I do not have any particular security issues in mind here, and if PMD need to copy keys internally, for alignment or padding purposes, redundancy problems can be overcome. My concern was, that it is the more natural way of handling the API; we have one key, multiple padding schemes, so we reflect this logic in the API.

Both options are widely used; libcrypto, for example is setting padding within session, other languages like Go, Rust are setting it as an argument to the method of the key struct.

If this is that problematic with VirtIO compatibility, I say this change is okay.

> > >
> > >
> > > >>> +* cryptodev: The rte_crypto_rsa_xform struct member to hold
> > > >>> +private key
> > > >>> +  in either exponent or quintuple format is changed from union
> > > >>> +to struct
> > > >>> +  data type. This change is to support ASN.1 syntax (RFC 3447 Appendix
> A.1.2).
> > > >>> +  This change will not break existing applications.
> > > > >
> > > > > This one I agree. RFC 8017 obsoletes RFC 3447.
> 
>
  
Gowrishankar Muthukrishnan Aug. 18, 2024, 4:36 a.m. UTC | #10
Hi Arek,

> I do not have any particular security issues in mind here, and if PMD need to
> copy keys internally, for alignment or padding purposes, redundancy problems
> can be overcome. My concern was, that it is the more natural way of handling
> the API; we have one key, multiple padding schemes, so we reflect this logic in
> the API.
> 
> Both options are widely used; libcrypto, for example is setting padding within
> session, other languages like Go, Rust are setting it as an argument to the
> method of the key struct.
> 
> If this is that problematic with VirtIO compatibility, I say this change is okay.
> 

Thank you for your input. I understand your concern. We ensure the impact 
Is nominal and make changes if needed.

Thanks,
  

Patch

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 6948641ff6..26fec84aba 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -147,3 +147,14 @@  Deprecation Notices
   will be deprecated and subsequently removed in DPDK 24.11 release.
   Before this, the new port library API (functions rte_swx_port_*)
   will gradually transition from experimental to stable status.
+
+* cryptodev: The struct rte_crypto_rsa_padding will be moved from
+  rte_crypto_rsa_op_param struct to rte_crypto_rsa_xform struct,
+  breaking ABI. The new location is recommended to comply with
+  virtio-crypto specification. Applications and drivers using
+  this struct will be updated.
+
+* cryptodev: The rte_crypto_rsa_xform struct member to hold private key
+  in either exponent or quintuple format is changed from union to struct
+  data type. This change is to support ASN.1 syntax (RFC 3447 Appendix A.1.2).
+  This change will not break existing applications.