Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

[Hubert Kario <[e-mail]>]

On Thursday, 12 December 2019 16:26:41 CET, Ryan Sleevi wrote:
> On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario <[e-mail]> 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