On Monday 25 January 2016 19:32:57 Andrey Jivsov wrote:
> 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?Because if PKCS#1 1.5 is available for HS, many implementations still won't implement PSS and we won't move one step. OTOH, if the PSS is mandatory, they have a clear need to add this support. 8% of servers in Alexa top 1 million websites still won't sign the Server Key Exchange with anything but SHA-1[1], despite the fact that you need to have an implementation of SHA-256 to implement TLSv1.2 in the first place. > 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. PSS in X.509 is not usable now because only fraction of clients and servers support it. That's why CA's don't sign certificates with it - to minimize support costs and reissue rates (in cases the customer finds out that he needs the "legacy" certificate). 1 - https://securitypitfalls.wordpress.com/2015/12/07/november-2015-scan-results/ -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
