On 01/22/2016 03:14 AM, Hubert Kario wrote:
On Thursday 21 January 2016 18:25:00 Andrey Jivsov wrote:
Current draft of TLS 1.3 [1] mandates RSA-PSS in TLS handshake by the
following language in sec 4.8.1
In RSA signing, the opaque vector contains the signature
generated
using the RSASSA-PSS signature scheme defined in [RFC3447
<http://tools.ietf.org/html/rfc3447>] with MGF1. The digest
used in the mask generation function MUST be the same as the
digest which is being signed (i.e., what appears in
algorithm.signature). The length of the salt MUST be equal to
the
length of the digest output. Note that previous versions of TLS
used
RSASSA-PKCS1-v1_5, not RSASSA-PSS.
The
struct {
SignatureAndHashAlgorithm algorithm;
opaque signature<0..2^16-1>;
} DigitallySigned;
defines RSA PKCS#1 1.5 and RSA PSS as "rsa" and "rsapss", see sec
A.3.1.1:
enum {
rsa(1),
dsa(2),
ecdsa(3),
rsapss(4),
eddsa(5),
(255)
} SignatureAlgorithm;
since draft -09 (posted Oct 2015). "rsa" applies to X.509 certificates
only.
Many implementers of TLS 1.3 expressed desire for the TLS 1.3 to be as
frictionless as possible regarding the upgrade of existing TLS
installations to TLS 1.3. We should expect that all TLS 1.3 servers
and clients will have support for older versions of TLS on the same
node. Ideally, it should be possible to upgrade the software /
firmware to add TLS 1.3 support on existing hardware with minimal
penalty.
The transition to TLS 1.3 is not urgent matter. Making sure that it is
as robust as possible is of higher importance than "making it easy to
implement for existing TLS1.2 implementations".
That's right there in the charter:
https://datatracker.ietf.org/wg/tls/charter/
The issue here is to be able to use existing hardware with TLS 1.3.
The CAs got PKCS#1 1.5 exemption under TLS 1.3. I suppose that the
reason HS did not get matching capability is it was believed that
PSS-only would not be a problem. I noted a few problems with PSS in HS.
The current list of FIPS 140 products that support RSA shows twice as
many products that support RSASSA-PKCS1_V1_5 than these that support
RSASSA-PSS [4]. There is greater than 50% chance to lose FIPS
certification with TLS 1.3, factoring client auth and servers.
You also need a FIPS certified implementation of HKDF. So yes, it most
likely will require new certifications.
HKDF is somewhat orthogonal to the this thread.
I was pointing out that there are devices, e.g. FIPS PCI cards or
smartcard, that "hold" RSA keys. Some of them can only do RSA PKCS#1 1.5
signing with these keys. These devices work with TLS 1.2 and won't work
with TLS 1.3. These problems might be fixable if vendors are willing to
do so, but observe that for FIPS devices this means more costly and
slower re-certification, not just firmware update.
Regarding HKDF, note that FIPS 140-2 specifically says that it doesn't
certify TLS, SSH, or protocols in general. It certifies crypto
primitives. Vendors are free to chose which crypto primitives they
certify (and this set is noted on the FIPS certificate).
KDFs in TLS are covered by
http://csrc.nist.gov/groups/STM/cavp/documents/components/askdfvs.pdf.
TLS 1.2 KDF is noted as "TLS KDF" on
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2014.htm .
Not many modules claim certification for TLS KDF for current TLS and
this may continue to be the case for HKDF in TLS.
In our case we do TLS KDF "ourselves" and I think other conceivable
implementations can do this too, so this is not an issue in this thread.
The only solution that's available at this point is conditioning TLS
1.3 support on appropriate hardware. For this reason TLS 1.3 it
probably won't be enabled by default in the product I work on. I
would prefer for TLS 1.3 to be enabled by default and write the code
to decide whether it does PSS or falls back to RSA PKCS1 1.5.
Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not cutting
it off now would be negligent.
You mean for HS only, while leaving it for X.509 certs?
More importantly, note that while I understand the intent to increase
security by mandating PSS in TLS 1.3, in practice it doesn't work.
We/our customers will have to select the highest protocol that works (or
is reasonably fast). If the spec is written to mean (TLS1.3 && PSS), if
we can't do PSS, we can't do TLS 1.3. There are other desirable security
enhancements in TLS 1.3, besides PSS, that would be nice to deploy.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
