Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1
On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote: On Wed, Dec 11, 2019 at 9:22 AM Ilari Liusvaara wrote: On Wed, Dec 11, 2019 at 02:21:48PM +0100, Hubert Kario wrote: On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wrote: One test I just tried: - Smartcard capable of raw RSA. - OpenSC PKCS#11 drivers. - Firefox ESR 68 - Server supports TLS 1.3 (Accept RSA PKCS#1v1.5 client signatures is enabled[2]). Result: Failed. Client hits internal error code SEC_ERROR_LIBRARY_FAILURE [3]. That doesn't match my understanding of how NSS works – AFAIK, NSS (and as such, Firefox), will try both raw RSA and rsa-pss signatures with the token, depending on what kind of algorithms the token advertises. I think the issue was the old version of OpenSC, new versions can do rsa-pss with rsa-raw: https://bugzilla.redhat.com/show_bug.cgi?id=1595626 https://github.com/OpenSC/OpenSC/pull/1435 Ok, upgrading the OpenSC to git master (0.20.0-rc34-2-gee78b0b8) makes client certificates in TLS 1.3 in Firefox work with that card (works even if accept RSA PKCS#1v1.5 client signatures is disabled on server side). There is apparently no release with the fix. One needs 0.20-rcX or recent git master. Chrome likewise tries to polyfill PSS support out of raw RSA when the underlying keys support it, but PSS support is still a problem. In particular, I believe TPM 1.2 can neither do RSA-PSS nor polyfill it with raw padding. (Oddly, the spec does reference OAEP, but signing is only PKCS#1 v1.5.) TPM 2.0 can do PSS, but hardware lifecycles are long. Between the negotiation ordering and the client certificate privacy flaw fixed in TLS 1.3, simply saying "no TLS 1.3 for those keys" is problematic. Thus, the draft. It's true that it adds some transitionary codepoints to TLS 1.3, but the point of TLS 1.3 was not switching to PSS. That's a minor bonus on top of *much* more important changes. Most properties negotiated by TLS can be unilaterally updated by the TLS-related components of a system. This is great because it means we can deploy TLS 1.3's improvements. The long-term credentials are one of the big exceptions here and, indeed, we didn't just make TLS 1.3 mandate Ed25519. We wanted to maintain continuity with existing RSA keys, but since it was possible to switch them to RSA-PSS we went ahead and did that. Sadly, it appears that last point can be more true for server keys than client keys. :-( If TLS 1.2 was looking insecure, I would be with you on this one. But given that TLS 1.2 can be configured to be as secure as TLS 1.3, I think introducing weak points to TLS 1.3, weak points we will have to live with for the next decade, if not two, is counter-productive and will only delay deployemnt of RSA-PSS capable HSMs. Not allowing PKCS#1 v1.5 in TLS 1.3 puts actual pressure to replace that obsolete hardware, without exposing users to unnecessary risk. -- 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
Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1
2019-12-12 06:51 GMT-05:00 Hubert Kario : > On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote: > > On Wed, Dec 11, 2019 at 9:22 AM Ilari Liusvaara > > wrote: > > > >> On Wed, Dec 11, 2019 at 02:21:48PM +0100, Hubert Kario wrote: > >>> On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wrote: > > One test I just tried: > > - Smartcard capable of raw RSA. > - OpenSC PKCS#11 drivers. > - Firefox ESR 68 > - Server supports TLS 1.3 (Accept RSA PKCS#1v1.5 client signatures is > enabled[2]). > > Result: Failed. Client hits internal error code > SEC_ERROR_LIBRARY_FAILURE > [3]. > >>> > >>> That doesn't match my understanding of how NSS works – AFAIK, NSS (and as > >>> such, Firefox), will try both raw RSA and rsa-pss signatures with the > >>> token, > >>> depending on what kind of algorithms the token advertises. > >>> > >>> I think the issue was the old version of OpenSC, new versions can do > >>> rsa-pss > >>> with rsa-raw: > >>> https://bugzilla.redhat.com/show_bug.cgi?id=1595626 > >>> https://github.com/OpenSC/OpenSC/pull/1435 > >> > >> Ok, upgrading the OpenSC to git master (0.20.0-rc34-2-gee78b0b8) makes > >> client certificates in TLS 1.3 in Firefox work with that card (works even > >> if accept RSA PKCS#1v1.5 client signatures is disabled on server side). > >> > >> There is apparently no release with the fix. One needs 0.20-rcX or recent > >> git master. > >> > > > > Chrome likewise tries to polyfill PSS support out of raw RSA when the > > underlying keys support it, but PSS support is still a problem. In > > particular, I believe TPM 1.2 can neither do RSA-PSS nor polyfill it with > > raw padding. (Oddly, the spec does reference OAEP, but signing is only > > PKCS#1 v1.5.) TPM 2.0 can do PSS, but hardware lifecycles are long. Between > > the negotiation ordering and the client certificate privacy flaw fixed in > > TLS 1.3, simply saying "no TLS 1.3 for those keys" is problematic. Thus, > > the draft. It's true that it adds some transitionary codepoints to TLS 1.3, > > but the point of TLS 1.3 was not switching to PSS. That's a minor bonus on > > top of *much* more important changes. > > > > Most properties negotiated by TLS can be unilaterally updated by the > > TLS-related components of a system. This is great because it means we can > > deploy TLS 1.3's improvements. The long-term credentials are one of the big > > exceptions here and, indeed, we didn't just make TLS 1.3 mandate Ed25519. > > We wanted to maintain continuity with existing RSA keys, but since it was > > possible to switch them to RSA-PSS we went ahead and did that. Sadly, it > > appears that last point can be more true for server keys than client keys. > > :-( > > If TLS 1.2 was looking insecure, I would be with you on this one. But given > that TLS 1.2 can be configured to be as secure as TLS 1.3 TLS 1.3 provides privacy for client certificates, which TLS 1.2 does not. > I think introducing > weak points to TLS 1.3, weak points we will have to live with for the next > decade, if not two, is counter-productive and will only delay deployemnt of > RSA-PSS capable HSMs. This draft is only about client authentication, it does not release pressure from server-side HSMs. I just had to hold back a Go crypto/tls deployment from TLS 1.3 due to the same issue that David encountered, so I'd support this draft. Leaving behind entire client hardware generations is not the same thing as enforcing progress in software implementations. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1
On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario wrote: > If TLS 1.2 was looking insecure, I would be with you on this one. But given > that TLS 1.2 can be configured to be as secure as TLS 1.3, I think > introducing > weak points to TLS 1.3, weak points we will have to live with for the next > decade, if not two, is counter-productive and will only delay deployemnt > of > RSA-PSS capable HSMs. Not allowing PKCS#1 v1.5 in TLS 1.3 puts actual > pressure > to replace that obsolete hardware, without exposing users to unnecessary > risk. > That risk calculus doesn't seem to make sense, or even be internally consistent? If we apply the logic you're applying here - that the non-existence within TLS 1.3 somehow exerts pressure on organizations to replace - then that pressure only exists because the value proposition of TLS1.3 to these organizations is greater than the cost of replacing that hardware. But as you seemingly state, the value proposition of TLS 1.3 is not significant, because "TLS 1.2 can be configured as secure as TLS 1.3". So what's the pressure these organizations would face that would have them wanting to adopt TLS1.3? It seems that, at least with the information provided, the existence or non-existence of PKCS#1v1.5 in TLS1.3 cannot be the force that exerts pressure. Similarly, this argument implies organizations are rational actors that evaluate these protocols based on the security strength. If they are indeed rational, then the presumed weakness of PKCS#1v1.5 (and not TLS 1.2 vs TLS 1.3) would naturally exert a pressure on organizations to replace this hardware, in order to leverage the better security of RSA-PSS. Thus the existence within TLS1.3 does not actually meaningfully change the calculus for security or for organizational pressure. Setting aside for a second arguments about whether RSA-PSS vs PKCS#1v1.5 (in the context of client certificates) is a significant security differentiator, or whether the security properties of TLS1.2 vs TLS1.3 is are significant enough to exert pressure, it also seemingly overlooks the privacy value afforded by TLS1.3's encryption. If we're trying to make cost-based assumptions here about what pressures will be exerted, I feel like we have ample evidence from the TLS 1.3 adoption that benefits in security and privacy do not actually exert pressures on organizations to change, because the incremental value they provide is outweighed by the costs. The middlebox challenges are a case-study in this. This draft attempts to reduce those costs, making it possible to take advantage of those incremental improvements made in 1.3. The distinction isn't going from good to going from bad, which seems to be implied by arguing against adoption, it's going from worse (TLS1.2, with no privacy affordances and the ample considerations around the key schedules) to something meaningfully better (TLS1.3), even if it's not ideal. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1
On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario wrote: > On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote: > > On Wed, Dec 11, 2019 at 9:22 AM Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > >> On Wed, Dec 11, 2019 at 02:21:48PM +0100, Hubert Kario wrote: > >>> On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wrote: > > One test I just tried: > > - Smartcard capable of raw RSA. > - OpenSC PKCS#11 drivers. > - Firefox ESR 68 > - Server supports TLS 1.3 (Accept RSA PKCS#1v1.5 client signatures is > enabled[2]). > > Result: Failed. Client hits internal error code > SEC_ERROR_LIBRARY_FAILURE > [3]. > >>> > >>> That doesn't match my understanding of how NSS works – AFAIK, NSS (and > as > >>> such, Firefox), will try both raw RSA and rsa-pss signatures with the > >>> token, > >>> depending on what kind of algorithms the token advertises. > >>> > >>> I think the issue was the old version of OpenSC, new versions can do > >>> rsa-pss > >>> with rsa-raw: > >>> https://bugzilla.redhat.com/show_bug.cgi?id=1595626 > >>> https://github.com/OpenSC/OpenSC/pull/1435 > >> > >> Ok, upgrading the OpenSC to git master (0.20.0-rc34-2-gee78b0b8) makes > >> client certificates in TLS 1.3 in Firefox work with that card (works > even > >> if accept RSA PKCS#1v1.5 client signatures is disabled on server side).. > >> > >> There is apparently no release with the fix. One needs 0.20-rcX or > recent > >> git master. > >> > > > > Chrome likewise tries to polyfill PSS support out of raw RSA when the > > underlying keys support it, but PSS support is still a problem. In > > particular, I believe TPM 1.2 can neither do RSA-PSS nor polyfill it with > > raw padding. (Oddly, the spec does reference OAEP, but signing is only > > PKCS#1 v1.5.) TPM 2.0 can do PSS, but hardware lifecycles are long. > Between > > the negotiation ordering and the client certificate privacy flaw fixed in > > TLS 1.3, simply saying "no TLS 1.3 for those keys" is problematic. Thus, > > the draft. It's true that it adds some transitionary codepoints to TLS > 1.3, > > but the point of TLS 1.3 was not switching to PSS. That's a minor bonus > on > > top of *much* more important changes. > > > > Most properties negotiated by TLS can be unilaterally updated by the > > TLS-related components of a system. This is great because it means we can > > deploy TLS 1.3's improvements. The long-term credentials are one of the > big > > exceptions here and, indeed, we didn't just make TLS 1.3 mandate Ed25519. > > We wanted to maintain continuity with existing RSA keys, but since it was > > possible to switch them to RSA-PSS we went ahead and did that. Sadly, it > > appears that last point can be more true for server keys than client > keys. > > :-( > > If TLS 1.2 was looking insecure, I would be with you on this one. But given > that TLS 1.2 can be configured to be as secure as TLS 1.3, I think > introducing > weak points to TLS 1.3, weak points we will have to live with for the next > decade, if not two, is counter-productive and will only delay deployemnt > of > RSA-PSS capable HSMs. Not allowing PKCS#1 v1.5 in TLS 1.3 puts actual > pressure > to replace that obsolete hardware, without exposing users to unnecessary > risk. > For client certificates, TLS 1.2 cannot be configured to be as secure as TLS 1.3. The client certificates are sent in the clear. https://tma.ifip.org/wordpress/wp-content/uploads/2017/06/tma2017_paper2.pdf You mentioned elsewhere you can renegotiate, but renegotiation doesn't work. It introduces a host of other problems from DoS risks to problems with changing the security state of a connection after the fact to general layering issues with the public API being odd. Some HTTP servers block renegotiation altogether (I believe NGINX does) and some TLS stacks don't support renegotiation as a server at all (BoringSSL and Go). More importantly, renegotiation is not supported with HTTP/2, which is an important improvement for performance and server load (fewer connections). Now, the HTTP/2 spec does say the following: > An endpoint MAY use renegotiation to provide confidentiality protection for client credentials offered in the handshake, but any renegotiation MUST occur prior to sending the connection preface. A server SHOULD request a client certificate if it sees a renegotiation request immediately after establishing a connection. However, I'm not aware of anyone implementing this, and I do not think this suggestion actually works. Chrome does not accept it as a client at all and will fail the connection, nor can I see any way to accept it. An HTTP/2 client speaks as soon as the handshake completes and does not know whether the server is going to do this. By the time the client receives a HelloRequest, it may have sent zero, one, or many HTTP requests. This means the fundamental ambiguities with a multiplexing protocol, as well as the handshake/app-data interle
Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1
On Thursday, 12 December 2019 16:26:41 CET, Ryan Sleevi wrote: On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario wrote: If TLS 1.2 was looking insecure, I would be with you on this one. But given that TLS 1.2 can be configured to be as secure as TLS 1.3, I think introducing weak points to TLS 1.3, weak points we will have to live with for the next decade, if not two, is counter-productive and will only delay deployemnt of RSA-PSS capable HSMs. Not allowing PKCS#1 v1.5 in TLS 1.3 puts actual pressure to replace that obsolete hardware, without exposing users to unnecessary risk. That risk calculus doesn't seem to make sense, or even be internally consistent? If we apply the logic you're applying here - that the non-existence within TLS 1.3 somehow exerts pressure on organizations to replace - then that pressure only exists because the value proposition of TLS1.3 to these organizations is greater than the cost of replacing that hardware. But as you seemingly state, the value proposition of TLS 1.3 is not significant, because "TLS 1.2 can be configured as secure as TLS 1.3". So what's the pressure these organizations would face that would have them wanting to adopt TLS1.3? It seems that, at least with the information provided, the existence or non-existence of PKCS#1v1.5 in TLS1.3 cannot be the force that exerts pressure. a). configuring TLS 1.3 to be secure is easier - so using TLS 1.3 automatically makes the use of it more secure b). the evaluation I am performing is time dependant - i.e. I'm talking about situation as it is *now,* in the future the situation may change and TLS 1.2 may become weak/insecure while TLS 1.3 will remain secure. Similarly, this argument implies organizations are rational actors that evaluate these protocols based on the security strength. If they are indeed rational, then the presumed weakness of PKCS#1v1.5 (and not TLS 1.2 vs TLS 1.3) would naturally exert a pressure on organizations to replace this hardware, in order to leverage the better security of RSA-PSS. Thus the existence within TLS1.3 does not actually meaningfully change the calculus for security or for organizational pressure. c). non-use of TLS 1.3 by an organisation is something that will be easy to notice by an auditor, use of PKCS#1 v1.5 with client certificates is not something that I would bet any money to be noticed by a typical auditor (e.g. PCI-DSS never went into such details) Setting aside for a second arguments about whether RSA-PSS vs PKCS#1v1.5 (in the context of client certificates) is a significant security differentiator, or whether the security properties of TLS1.2 vs TLS1.3 is are significant enough to exert pressure, it also seemingly overlooks the privacy value afforded by TLS1.3's encryption. it doesn't, because deploying renegotiation in TLS 1.2 to encrypt client certificates is neither complex nor unheard-of If we're trying to make cost-based assumptions here about what pressures will be exerted, I feel like we have ample evidence from the TLS 1.3 adoption that benefits in security and privacy do not actually exert pressures on organizations to change, because the incremental value they provide is outweighed by the costs. The middlebox challenges are a case-study in this. This draft attempts to reduce those costs, making it possible to take advantage of those incremental improvements made in 1.3. middleboxes affect many connections, client certificates are used by small minority of connections in very special deployments The distinction isn't going from good to going from bad, which seems to be implied by arguing against adoption, it's going from worse (TLS1.2, with no privacy affordances and the ample considerations around the key schedules) to something meaningfully better (TLS1.3), even if it's not ideal. my argument is that TLS 1.2 is only potentially worse, not provably worse, at least now -- 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
Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1
On Thursday, 12 December 2019 16:50:45 CET, David Benjamin wrote: On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario wrote: On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote: ... ... some TLS stacks don't support renegotiation as a server at all (BoringSSL and Go). ... Chrome does not accept it ... so because Google decided one thing, everybody has to bow down to it? and, sorry, but I consider the privacy angle a red herring, nobody is doing proper AppData padding, so the connections leak privacy information in TLS 1.3 like a sieve too An endpoint MAY use renegotiation to provide confidentiality protection for client credentials offered in the handshake An HTTP/2 client speaks as soon as the handshake completes and does not know whether the server is going to do this. if privacy was so important why nobody worked on it with HTTP/2? It's not like much has changed in the last 4 years on that front. sorry, I'm not buying that argument -- 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
Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT)
On Wed, Dec 11, 2019 at 12:48:58PM -0500, Russ Housley wrote: > Mirja: > > > -- > > COMMENT: > > -- > > > > Just a small thing to double-check: I wonder if this sentence would actually > > require an update to RFC8446: > > "TLS 1.3 does not permit the server to send a CertificateRequest > > message when a PSK is being used. This restriction is removed when > > the "tls_cert_with_extern_psk" extension is negotiated, allowing > > certificate-based authentication for both the client and the server." > > Or maybe it should be phrased differently, just: > > "If the "tls_cert_with_extern_psk" extension is negotiated, > > certificate-based > > authentication is allowed for both the client and the server." I guess it > > depends on what exactly is said in RFC8446 (and I didn't went and tried to > > find > > it). > > I do not believe that an update is needed or appropriate. First, the > presence of this extension is an indication that this behavior will be > different. Second, this is going to be an Experimental RFC, so it should not > update a standards-track RFC. I agree; this is just an extension working as normal. (Not that I haven't asked the same question before for other documents) -Ben > > And as a side note, it is usually recommended to provide the link to the > > registry in the IANA section (to make life for IANA easier) > > I will gladly add a reference to the registry: > > https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml > > Russ > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
