On 01/25/2016 03:11 PM, Russ Housley wrote:
On Jan 25, 2016, at 2:43 PM, Hubert Kario wrote:
On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote:
On 01/22/2016 01:14 PM, Hubert Kario wrote:
On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote:
On 01/22/2016 03:14 AM, Hubert Kario wrote:
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?
If we don't do it for HS in TLS first, we'll never get rid of it in
X.509 certs.
We need to start somewhere, and it's more reasonable to expect that
hardware with support for new protocols will get updated for RSA-PSS
handling than that libraries and hardware will suddenly start
implementing it in droves just in anticipation of the time when CAs
_maybe_ will start issuing certificates signed with RSA-PSS.
Isn't it more a matter of TLS being a consumer of external PKIX
infrastructure, the web PKI, etc.? They are out of the reach of the
IETF TLS working group; any requirements we attempted to impose would
be unenforceable, even if there was an Internet Police (which there
is not).
TLS will happily use PKCS#1 v1.5 signed X.509 certificates, so how
exactly is creating a side effect of increasing the deployment rate of
RSA-PSS _in TLS implementations_ an "overreach"?!
I have been a supporter of PSS for a very long time -- see RFC 4055.
We have many algorithm transition issues, but this is one place where we have
seen very little progress. I would like to see support for PSS in the
protocol, even if we need to support PKCS v1.5 for certificate signatures for a
long time.
Is there evidence that hard-wiring {PSS} in HS and {PSS, PKCS#1 1.5}
with X.509 certs will lead to better PSS adoption than if {PSS, PKCS#1
1.5} were available in both HS and X.509 certs?
This should be balanced against the reality that PSS in HS with TLS 1.3
guarantees lower TLS 1.3 adoption as I wrote above. PSS-only in TLS 1.3
HS may make code more complex as well.
I am trying to imagine a logic that a TLS 1.3 client supporting
smartcard client authentiation would need to implement, assuming
mandatory PSS signing in HS, e.g. a case of Firefox + PKCS#11 interface
with a smartcard.
First, the code should query (attached? logged-in?) smartcard(s) to
determine if the key(s) on the smartcard that might be used for client
authentication can do PSS signing. PKCS#11 interface lists the PSS
capability as CKM_SHA256_RSA_PKCS_PSS mechanism. If no such PSS+hash
mechanism is available, the code needs to tag the keys(s) as TLS
1.2-only. When the client connects to a TLS 1.3 server and the server
requests client authentication with the non-PSS key, I think this will
require protocol dance down to TLS 1.2 (insecure TLS fallback).
Alternatively, the client will need to start from TLS 1.2 when it
detected such a smartcard, for any server.
The underlying reasons why CAs can't sign with PSS v.s. TLS server or
client are probably overlapping in many cases: FIPS 140, HSM, hardware.
The all-or-nothing approach to PSS sin HS eems inconsistent with
traditional feature negotiation in TLS HS.
Russ
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
