On Thursday, 12 December 2019 16:26:41 CET, Ryan Sleevi wrote:
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.
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
