On Mon, Oct 21, 2019 at 9:42 AM Hubert Kario <hka...@redhat.com> wrote:
> On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote: > > This email starts a call for adoption of draft-davidben-tls13-pkcs1-00, > > which can be found here: > > > > https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00 > > > > It will run until November 1, 2019. Please indicate whether or not you > would > > like to see this draft adopted and whether you will review and provide > > feedback on it going forward. > > Yes, requiring RSA-PSS causes interoperability issues with smartcards that > don't implement this 16 year old algorithm. But being able to say "if > you're > using TLS 1.3 that means you are not using legacy crypto" has non > insignificant value too. > > This document erodes that. > The document goes into the rationale here under Security Considerations. I'm unhappy about this too, but our experience is that devices without PSS support are fairly common in client certificates. The negotiation order means that accounting for such devices effectively means servers hold back TLS 1.3 for *all* their clients, not just those that are affected. Additionally, even if one could get the negotiation order correct, TLS 1.3 fixes a serious privacy leak with client certificates. Keeping those clients on TLS 1.2 means they continue to leak their identity over the network. To mitigate the second-order effects, the document intentionally makes the code points client-only (the above motivations don't apply for server keys), as well as allocating separate code points from the existing PKCS#1 values. If a client or server wishes to not use[*] PKCS#1 signatures in TLS 1.3, it doesn't need to advertise/accept those code points. TLS libraries probably should also disable them by default. Given all that, I think adding code points for deployments that need them is the right tradeoff. [*] PKCS#1 signatures in certificates and the downgrade-sensitivity of the TLS 1.2 signature aside. > So I'm against adoption of this draft by the WG. > > If it is adopted, I will review and provide feedback on it. > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech > Republic_______________________________________________ > 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
