On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario <hka...@redhat.com> 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
