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. > 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 had to wait for XP SP2 to be over 10 years old for the CA's to even _consider_ using anything but SHA-1 for signatures. And most of them did that only on explicit request when requesting certificates. If new signature types can't be deployed for new protocols they will never get deployed. There always will be implementations that do the absolute minimum to get interoperability *right now* and not a single extra step. -- 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
