> On 2 Mar 2016, at 3:03 AM, Andrey Jivsov <[email protected]> wrote: > > On 03/01/2016 11:20 AM, Yoav Nir wrote: >> >> On 1 Mar 2016, at 8:23 PM, Alyssa Rowan <[email protected]> wrote: >> >>>> [YN] It would be cool to ban PKCS#1.5 from certificates, but we >>>> are not the PKIX working group. Nor are we the CA/Browser forum. >>>> When a CA issues a certificate it has to work with every client >>>> and server out there, When we use TLS 1.3, the other side supports >>>> TLS 1.3 as well, so it’s fair to assume that it knows PSS. >>> >>> Perhaps the PKIX working group and CAB/Forum could both use a friendly >>> reminder not to ignore how perilous using RSA PKCS#1 v1.5 still remains? >> >> Neither you nor I can post in any of the CA/Browser forum’s lists, because >> neither of us has either a browser or a public CA. >> >> There are some people who are active there and are reading this list, so >> they might take such a proposal there. I’m not very optimistic, though. >> While only CAs and browsers are members, they are keenly aware that even the >> public CAs have a wide variety of relying parties, running all sorts of >> software. And it’s much harder to scan clients than it is to scan servers, >> so it’s difficult to say how many clients will not be able to connect to a >> server with a certificate signed with RSA-PSS. Probably far too many for the >> CA/BF to be comfortable deprecating PKCS#1. >> >> The PKIX working group has shut down several years ago. The Curdle WG is a >> new working group whose charter includes deprecating obsolete stuff. Perhaps >> they might be interested. >> >> Yoav >> > > The removal of PKCS #1.5 signature support in TLS 1.3 is a client issue when > client authentication is used. See examples here: > https://www.ietf.org/mail-archive/web/tls/current/msg19096.html . > > Regarding server-only authentication, it seems that there is assumption that > TLS 1.3 will continue to use PKCS#1.5 for a long time in X.509 certs. Then > why "break Internet" or slow down adoption of TLS 1.3 by mandating PSS in one > field of handshake?
The easy answer is: because we can. We can’t mandate for the CA industry what kind of certificates they should issue, or rather, we can, but they’ll rightly ignore us. We *can* mandate how a new TLS 1.3 implementation signs for another new TLS 1.3 implementation. Mandating that the certificates are signed with PSS would definitely slow down the adoption of TLS 1.3. Mandating what algorithm is used within the protocol does not. As long as the spec allows PKCS#1 all implementations will support it and many implementors will delay PSS because it’s not needed for interoperability. That’s what a rational manager would do: implement TLS 1.3 with PKCS#1 now, and place implementing PSS “on the roadmap”. I don’t think we should give them that incentive. > Imagine that there is PSS#2 in the future. Is the intent to issue new TLS 1.4 > that bans PSS and hardwires PSS#2? If not, there may still be a signature > negotiation mechanism in TLS 1.3 in the future. That depends. Did we find that PSS is insecure in this future? > The reasons CAs are cold to adoption of PSS are similar to these of TLS > servers or clients: 3d-party dependence, prior investment, FIPS 140 > certification, cost. Both servers and clients tend to use libraries that implement both the protocol and the algorithms. OpenSSL springs to mind, as do NSS, GNUTLS, SChannel and whatever Apple calls their library. Sure there are separate libraries with software handshakes and hardware algorithms. Even OpenSSL does this with their “engines”. I don’t think this is reason enough to keep dragging obsolete algorithms with us. > TLS WG can ban PKCS #1.5 in CA certs in TLS 1.3, but it wisely doesn't. Why > one signature field is an exception? IMO this will lead to slower adoption of > TLS 1.3, on balance. Nothing prevents e.g. OpenSSL from implementing PSS in > HS (which is proposed as MUST anyway). Nothing prevents servers from not > negotiating TLS 1.3. Because this is a particular field that we control. Yoav _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
