I've done a tiny bit of checking on the situation of where we (USG DOD) have smartcards doing client auth TLS. To my knowledge, most (all?) are currently TLS 1.2 w/ PKCS1v1.5 certs. So, I would be in favor of this update (when I wrote RFC9151 I had long discussions about this, because I was worried about it then).
This is a problem that will go away with the adoption of PQ asymmetric algorithms. Deb Cooley NSA/CSD deco...@radium.ncsc.mil On Mon, Oct 30, 2023 at 11:37 AM Andrei Popov <Andrei.Popov= 40microsoft....@dmarc.ietf.org> wrote: > Correct, hardware update takes years. Deployments that use client crypto > devices without RSA-PSS support (or with an RSA-PSS implementation that > produces TLS 1.3-incompatible signatures) have to disable TLS 1.3 on the > client and/or server side. > > > > In a lot of these deployments the system admin can detect incompatible > client crypto devices and update TLS stacks as needed. > > > > Cheers, > > > > Andrei > > > > *From:* David Benjamin <david...@chromium.org> > *Sent:* Friday, October 27, 2023 11:34 AM > *To:* Benjamin Kaduk <bka...@akamai.com> > *Cc:* Andrei Popov <andrei.po...@microsoft.com>; TLS@ietf.org > *Subject:* [EXTERNAL] Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for > TLS 1.3 > > > > On Fri, Oct 27, 2023 at 2:07 PM Benjamin Kaduk <bka...@akamai.com> wrote: > > On Tue, Oct 24, 2023 at 10:12:56PM -0400, David Benjamin wrote: > > Additionally I want to emphasize that, because of the negotiation > order > > between versions and client certificates, there is no way to do an > > incremental transition here. Saying deployments stick with 1.2 not > only > > impacts the relevant hardware but also *any other connections that the > > server makes*. Essentially the server cannot enable TLS 1.3 until > *every* > > client has stopped using one of these PSS-incapable signers. This is > not a > > good transition plan. > > I think we should probably think out the transition plan here a bit more. > Sure, if we can have updated clients offer new SignatureSchemes and the > server > notice that to let them use TLS 1.3. But how does the server get to a > place > where it can use TLS 1.3 with every client that offers it? It seems like > it > has to know that all clients with old hardware tokens have updated, which > would > require knowing about and tracking exactly which clients those are, since > other > clients would not be sending the new SignatureSchemes in the first place. > I > see this getting a small win for the legacy clients but no improvement for > other clients or the server's default behavior. Am I missing something? > > > > Good question. You're right that, because we didn't do this from day > one[*], the transition plan is not ideal. > > > > Updating software is a lot easier than replacing hardware, so I think > waiting for clients with old hardware tokens to update (at least those that > have enabled TLS 1.3) can be viable. Most client certificate deployments > that stick keys in interesting hardware tokens are relatively closed > ecosystems on the client half, such as a managed enterprise deployment. You > need to have a provisioning process that knows to use the TPMs. In those > cases, it is viable for the enterprise to rollout client support for these > legacy codepoints, wait a bit, and then start enabling TLS 1.3 on the > servers. > > > > Andrei is probably better to speak to how commonly that plan would and > wouldn't be viable. If there are enough deployments where this doesn't > work, I suppose we could define a ClientHello extension that means "I will > either speak the legacy RSASSA-PKCS1-v1_5 codepoints, or it is not relevant > to me". Those semantics are pretty messy though, and it makes > the server-random downgrade hack much more complex. We can always do it > later if enough folks need it, so I'm inclined to defer it for now. > > > > David > > > > [*] As I recall, TLS 1.3 was broadly intended to be deployable with the > same keys as TLS 1.2, otherwise we probably needn't have bothered with RSA > at all. We switched from PKCS#1 v1.5 to PSS mostly because it was perceived > to cost us nothing. This was broadly true for server certificates. Client > certificates not so much. In hindsight, I think banning PKCS#1 v1.5 for > client signatures was a tad too ambitious for TLS 1.3. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
