Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

[Andrey Jivsov <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls