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

From: Darin Pettis <[email-masked]>
Date: Fri, 6 Dec 2019 11:09:48 -0600

On Thu, Nov 14, 2019 at 4:43 PM Adam Langley <[email-masked]>
wrote: People on this list who manage large corporate networks may wish to
pay attention to this: while you may not have updated servers to TLS 1.3
yet, eventually it'll happen and I suspect some will find a significant
amount of things like TPMs, in which you currently have client-certificate
keys, which only sign with PKCS#1 v1.5. Without this draft adopted and
implemented ahead of time, it's going to be painful.

Adam - Wanted to thank you for the call-out to people on the list managing
large corporate networks.  Looking into the mutual authentication supported
protocols issue that you and David raised.  Will evaluate potential future
impact.

Cheers,
Darin

On Thu, Nov 14, 2019 at 4:43 PM Adam Langley <[email-masked]> wrote:

> On Mon, Nov 11, 2019 at 11:33 AM Christopher Wood <[email-masked]>
> wrote:
>
>> The adoption call is now (belatedly) finished. At this time, there's not
>> enough interest to take this on as a WG item. We encourage further
>> discussion on the list, perhaps based on subsequent draft updates, and will
>> revisit adoption in the future if interest grows.
>>
>
> People on this list who manage large corporate networks may wish to pay
> attention to this: while you may not have updated servers to TLS 1.3 yet,
> eventually it'll happen and I suspect some will find a significant amount
> of things like TPMs, in which you currently have client-certificate keys,
> which only sign with PKCS#1 v1.5. Without this draft adopted and
> implemented ahead of time, it's going to be painful.
>
>
> Cheers
>
> AGL
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 7 Dec 2019 12:20:17 +0200

> protocols issue that you and David raised.  Will evaluate potential future

There are also library issues where the physical device does allow
RSA-PSS (e.g., because they can perform raw RSA root on arbitrary
values[1]), but libraries/drivers do not support it.

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].

[1] Yeah, not great for security, but some devices are like that.

[2] That option was a hack to make things work with Firefox ESR 52,
which did send RSA PKCS#1v1.5 client signature (scheme 0x0401) in
comparable situation.

[3] My guess would be that browser asks drivers for RSA-PSS, which they
do not support, causing the error.

-Ilari

---

From: Hubert Kario <[email-masked]>
Date: Wed, 11 Dec 2019 14:21:48 +0100

On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wrote:
>>> which only sign with PKCS#1 v1.5. Without this draft adopted and ...
>> 

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

-- 
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

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 11 Dec 2019 16:21:55 +0200

On Wed, Dec 11, 2019 at 02:21:48PM +0100, Hubert Kario wrote:
> such, Firefox), will try both raw RSA and rsa-pss signatures with the token,
> I think the issue was the old version of OpenSC, new versions can do rsa-pss
> with rsa-raw:

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.

-Ilari

---

From: David Benjamin <[email-masked]>
Date: Wed, 11 Dec 2019 12:06:19 -0500

> There is apparently no release with the fix. One needs 0.20-rcX or recent

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.
:-(

David

---

From: Hubert Kario <[email-masked]>
Date: Thu, 12 Dec 2019 12:51:24 +0100

> 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

---

From: "Filippo Valsorda" <[email-masked]>
Date: Thu, 12 Dec 2019 10:25:55 -0500

2019-12-12 06:51 GMT-05:00 Hubert Kario <[email-masked]>:
> 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
> 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.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 12 Dec 2019 10:26:41 -0500

> to replace that obsolete hardware, without exposing users to unnecessary

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.

---

From: David Benjamin <[email-masked]>
Date: Thu, 12 Dec 2019 10:50:45 -0500

> to replace that obsolete hardware, without exposing users to unnecessary

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 interleave problems, are immediately present.
Conversely, as a server, the client may have sent arbitrarily many HTTP
requests before it processed the HelloRequest, so the server must buffer
them all up (DoS risk) or process them anonymously (changing security state
mid-connection and not the same semantics as initial handshake
authentication).

David

---

From: Hubert Kario <[email-masked]>
Date: Thu, 12 Dec 2019 16:58:39 +0100

> existence or non-existence of PKCS#1v1.5 in TLS1.3 cannot be the force that

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.

> 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)

> 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

> 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

> 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

---

From: Hubert Kario <[email-masked]>
Date: Thu, 12 Dec 2019 17:26:35 +0100

On Thursday, 12 December 2019 16:50:45 CET, David Benjamin wrote:
>> On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote: ...
>
> ... some TLS stacks don't
> ... 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

>> 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

---

From: Nick Harper <[email-masked]>
Date: Thu, 12 Dec 2019 12:55:42 -0800

> proper AppData padding, so the connections leak privacy information in TLS

Privacy isn't a red herring. There's a big difference between leaking
ciphertext lengths vs leaking the user's name, email address, and other PII
present in a client cert when the client cert is sent in the clear.

> much has changed in the last 4 years on that front.

HTTP/2 couldn't fix the issue with TLS 1.2 client certs being sent in the
clear, but that problem was solved in TLS 1.3. Many of the problems not
solved by H2 are being worked on in QUIC. It takes time to develop and
deploy these protocols. Don't let perfect be the enemy of good.

---

From: Hubert Kario <[email-masked]>
Date: Fri, 13 Dec 2019 13:16:54 +0100

On Thursday, 12 December 2019 21:55:42 CET, Nick Harper wrote:
>>>  ...
> Privacy isn't a red herring.

it is in discussion about signature mechanisms supported by legacy hardware

> There's a big difference between leaking

which can be workarounded by doing client authentication in renegotiation
handshake, the feature is there in the protocol, it's not IETF fault that
some people decided to remove support for it

>>>> ...
>>> An HTTP/2 client speaks as soon as the handshake completes 
>>> and does not ...
>>> know
> clear,

again, renegotiation

> but that problem was solved in TLS 1.3. Many of the problems not
> deploy these protocols.

and which part of QUIC addresses length hiding? Because either privacy is
important, and it should be addressed by it, or mentioning privacy here is 
a red
herring.

> Don't let perfect be the enemy of good.

no, it's not a question of "perfect" or "good", it's a question of putting
legacy stuff in modern protocol or keeping it in legacy protocol, where its
use is obvious and easy to audit.
-- 
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