Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
On Fri, Oct 27, 2023 at 2:07 PM Benjamin Kaduk 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
Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
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? -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
On Fri, Oct 27, 2023 at 9:06 AM David Benjamin wrote: > Responses inline. > > On Fri, Oct 27, 2023 at 5:04 AM Michael P1 wrote: > >> Hi All, >> >> Thank you for this interesting draft, I had a couple of quick questions. >> >> OpenSSL has been mentioned in this thread, but I was wondering if you had >> examples of other implementations or services that use the "key_share >> first" algorithm outlined in Section 3.1 of the draft, so that as this >> document is taken forward it's both clear what the impact is and what needs >> to be updated? >> > I have not done a full audit of every TLS implementation to identify which > are key-share-first. From the thread, it sounds like rustls also needs to > be updated. I imagine there are others. However, "needs to be updated" is a > bit subtle. As the draft discusses, a key-share-first algorithm is fine *if > all your supported groups are equally preferable*. In that case, > prioritizing performance is reasonable. For instance, if you only implement > X25519 and P-256, it's probably fine to just pick based on key shares. So > if those implementations only implement a small handful of ECDH curves and > have such a policy, there's no immediate problem. > LibreSSL also needs an update, while the code is completely different it does use the same mechanism which is basically to just pick the prediction if at all possible to avoid the HRR, considering everything else as equivalently "good enough". In the old world where there really wasn't a practical "downgrade" this was a perfectly reasonable choice to make, so I expect the majority of implementations will need to be modified.. Fortunately it's not a difficult change. > > The problem is that this condition will obviously fail once we have a mix > of postquantum and classical groups. So, at minimum, any such > implementation needs to be fixed before deploying PQ. It is also quite > questionable if the TLS library documents that some configuration is a > preference list (as OpenSSL does), because the library would not actually > be implementing a preference list with a key-share-first algorithm. If your > library has pluggable groups (as OpenSSL does), this is also questionable > as that means the TLS library probably does not actually know that all > implemented groups are equally preferable. > > BoringSSL implements a preference-aware algorithm because we anticipated > this. :-) I believe NSS's algorithm is similarly preference-aware. But > clearly not everyone realized this when reading RFC 8446, so I think we > need to fix the specification text to be clearer. In particular, this > should be fixed before postquantum is widely implemented and we have a mess > on our hands. > > Similarly, in Section 3.2 of the draft, can we be explicit about what we >> mean by "best common option"? As mentioned in the thread, some servers may >> prefer size/speed, and others security level. This is particularly relevant >> in the PQ algorithms case, but also applies to current implementations >> choosing between x25519 and secp384r1, for example. >> > This is precisely why "best" is intentionally vague, and I think needs to > stay that way. TLS specs have always left the exact selection policy up to > implementation. Rather, we give semantics to the offering party's messages > (e.g. we say the client list is its preferences) and leave the selecting > party's response up to choice. However, we neglected to give semantics to > the client's key_share list, and have ended up in a place where reasonable > client and reasonable server behaviors do not mesh quite right. This draft > aims to correct that. > > >> DNS hints may not help decide which is best as we explicitly are not >> using key_shares. >> > I don't understand this comment. The point of DNS hints is not to help > decide which is best. It's to help the client decide which to predict, in > order to minimize roundtrips. The entire point of this draft is to clarify > that the client's prediction set is *not* a statement preference. I.e. it > is explicitly not about deciding which is best. > > Just to clarify, is the purpose of this draft to use new, duplicate groups >> for TLS to indicate that the server adheres to this draft? >> > No, this draft does *NOT* propose to define duplicate groups. > > The proposal is that *going forward*, any *new* groups we define will be > prediction-safe. In particular, we need to make sure that all post-quantum > groups are prediction-safe, so that we can better navigate the tradeoffs > between wanting to reliably negotiation postquantum groups, and their size > cost. It is, broadly, not a problem for existing ECDH groups because the > commonly implemented ones are all broadly of the same security level and > size. I don't believe there's been a significant need for clients to play > interesting prediction games. Thus, leaving them prediction-unsafe is just > fine. Indeed, the other half of the draft sets client rules that ensure > prediction-unsafe
Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
This is a good document and should be adopted. I have a mild preference for a separate document because I think it is important to keep this separate from 8446 because it would require less work (at least in the doc review aspect) for programmers to fix, and I am worried that it would “get lost” in 8446bis. I think the rationale around why this is important for PQ should have more, scary, words. But that can be fixed during WG time. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
Responses inline. On Fri, Oct 27, 2023 at 5:04 AM Michael P1 wrote: > Hi All, > > Thank you for this interesting draft, I had a couple of quick questions. > > OpenSSL has been mentioned in this thread, but I was wondering if you had > examples of other implementations or services that use the "key_share > first" algorithm outlined in Section 3.1 of the draft, so that as this > document is taken forward it's both clear what the impact is and what needs > to be updated? > I have not done a full audit of every TLS implementation to identify which are key-share-first. From the thread, it sounds like rustls also needs to be updated. I imagine there are others. However, "needs to be updated" is a bit subtle. As the draft discusses, a key-share-first algorithm is fine *if all your supported groups are equally preferable*. In that case, prioritizing performance is reasonable. For instance, if you only implement X25519 and P-256, it's probably fine to just pick based on key shares. So if those implementations only implement a small handful of ECDH curves and have such a policy, there's no immediate problem. The problem is that this condition will obviously fail once we have a mix of postquantum and classical groups. So, at minimum, any such implementation needs to be fixed before deploying PQ. It is also quite questionable if the TLS library documents that some configuration is a preference list (as OpenSSL does), because the library would not actually be implementing a preference list with a key-share-first algorithm. If your library has pluggable groups (as OpenSSL does), this is also questionable as that means the TLS library probably does not actually know that all implemented groups are equally preferable. BoringSSL implements a preference-aware algorithm because we anticipated this. :-) I believe NSS's algorithm is similarly preference-aware. But clearly not everyone realized this when reading RFC 8446, so I think we need to fix the specification text to be clearer. In particular, this should be fixed before postquantum is widely implemented and we have a mess on our hands. Similarly, in Section 3.2 of the draft, can we be explicit about what we > mean by "best common option"? As mentioned in the thread, some servers may > prefer size/speed, and others security level. This is particularly relevant > in the PQ algorithms case, but also applies to current implementations > choosing between x25519 and secp384r1, for example. > This is precisely why "best" is intentionally vague, and I think needs to stay that way. TLS specs have always left the exact selection policy up to implementation. Rather, we give semantics to the offering party's messages (e.g. we say the client list is its preferences) and leave the selecting party's response up to choice. However, we neglected to give semantics to the client's key_share list, and have ended up in a place where reasonable client and reasonable server behaviors do not mesh quite right. This draft aims to correct that. > DNS hints may not help decide which is best as we explicitly are not using > key_shares. > I don't understand this comment. The point of DNS hints is not to help decide which is best. It's to help the client decide which to predict, in order to minimize roundtrips. The entire point of this draft is to clarify that the client's prediction set is *not* a statement preference. I.e. it is explicitly not about deciding which is best. Just to clarify, is the purpose of this draft to use new, duplicate groups > for TLS to indicate that the server adheres to this draft? > No, this draft does *NOT* propose to define duplicate groups. The proposal is that *going forward*, any *new* groups we define will be prediction-safe. In particular, we need to make sure that all post-quantum groups are prediction-safe, so that we can better navigate the tradeoffs between wanting to reliably negotiation postquantum groups, and their size cost. It is, broadly, not a problem for existing ECDH groups because the commonly implemented ones are all broadly of the same security level and size. I don't believe there's been a significant need for clients to play interesting prediction games. Thus, leaving them prediction-unsafe is just fine. Indeed, the other half of the draft sets client rules that ensure prediction-unsafe groups continue to work fine, even with the old server behavior. If so, would a simpler option be to update servers to use the guidance in > Section 4.2.7 of RFC8446 to use the information in a successful handshake > to change the groups used in the key_share in subsequent connections? Worst > case here is that we have a suboptimal choice on first connection which can > be improved on even when HRR is not an option. > No, I don't think that works. The worst case scenario you describe is actually quite bad. The "suboptimal choice" here is to not pick a postquantum option when we should have. This means this suboptimal traffic is not protected against store
Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
It's OK, just appeared on the admin page. The Uni email can be pretty messed up sometimes so whenever things seem to take too long I check that they're actually still working. All fine, as you were :-). Peter. From: TLS on behalf of Michael P1 Sent: Friday, 27 October 2023 22:04 To: Rob Sayre; David Benjamin Cc: tls@ietf.org Subject: Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt Hi All, Thank you for this interesting draft, I had a couple of quick questions. OpenSSL has been mentioned in this thread, but I was wondering if you had examples of other implementations or services that use the "key_share first" algorithm outlined in Section 3.1 of the draft, so that as this document is taken forward it's both clear what the impact is and what needs to be updated? Similarly, in Section 3.2 of the draft, can we be explicit about what we mean by "best common option"? As mentioned in the thread, some servers may prefer size/speed, and others security level. This is particularly relevant in the PQ algorithms case, but also applies to current implementations choosing between x25519 and secp384r1, for example. DNS hints may not help decide which is best as we explicitly are not using key_shares. Just to clarify, is the purpose of this draft to use new, duplicate groups for TLS to indicate that the server adheres to this draft? If so, would a simpler option be to update servers to use the guidance in Section 4.2.7 of RFC8446 to use the information in a successful handshake to change the groups used in the key_share in subsequent connections? Worst case here is that we have a suboptimal choice on first connection which can be improved on even when HRR is not an option. As a way forward, would it be worth working on this in rfc8446bis to clarify the desired behaviour? An example change would be to Section 2.1 which implies preference for key_share first selection. Thanks, Michael From: Rob Sayre Sent: Tuesday, October 17, 2023 9:08 PM To: David Benjamin Cc: Andrei Popov ; tls@ietf.org Subject: Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt On Tue, Oct 17, 2023 at 12:32 PM David Benjamin mailto:david...@chromium.org>> wrote: > Server-side protection against [clients adjusting HRR predictions on > fallback] is not effective. Especially when we have both servers that cannot > handle large ClientHello messages and servers that have buggy HRR. I think the discussion about buggy HRR is a red herring. I agree with almost everything in the email except for this part. It's even worse than HRR, isn't it? The initial ClientHello will fail if spread across too many packets on some implementations, and then a new ClientHello will be sent using X25519 unless you want to lose customers. The client won't get an HRR back on the first try, the stuff just breaks (it's their bug, but it must be dealt with). But, if the DNS says it should work, it should be ok to fail there. The trustworthiness of this hint must also be weighed with ECH. So, if you're using SVCB with this idea and ECH, it seems pretty reasonable to me. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
Hi All, Thank you for this interesting draft, I had a couple of quick questions. OpenSSL has been mentioned in this thread, but I was wondering if you had examples of other implementations or services that use the "key_share first" algorithm outlined in Section 3.1 of the draft, so that as this document is taken forward it's both clear what the impact is and what needs to be updated? Similarly, in Section 3.2 of the draft, can we be explicit about what we mean by "best common option"? As mentioned in the thread, some servers may prefer size/speed, and others security level. This is particularly relevant in the PQ algorithms case, but also applies to current implementations choosing between x25519 and secp384r1, for example. DNS hints may not help decide which is best as we explicitly are not using key_shares. Just to clarify, is the purpose of this draft to use new, duplicate groups for TLS to indicate that the server adheres to this draft? If so, would a simpler option be to update servers to use the guidance in Section 4.2.7 of RFC8446 to use the information in a successful handshake to change the groups used in the key_share in subsequent connections? Worst case here is that we have a suboptimal choice on first connection which can be improved on even when HRR is not an option. As a way forward, would it be worth working on this in rfc8446bis to clarify the desired behaviour? An example change would be to Section 2.1 which implies preference for key_share first selection. Thanks, Michael From: Rob Sayre Sent: Tuesday, October 17, 2023 9:08 PM To: David Benjamin Cc: Andrei Popov ; tls@ietf.org Subject: Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt On Tue, Oct 17, 2023 at 12:32 PM David Benjamin mailto:david...@chromium.org>> wrote: > Server-side protection against [clients adjusting HRR predictions on > fallback] is not effective. Especially when we have both servers that cannot > handle large ClientHello messages and servers that have buggy HRR. I think the discussion about buggy HRR is a red herring. I agree with almost everything in the email except for this part. It's even worse than HRR, isn't it? The initial ClientHello will fail if spread across too many packets on some implementations, and then a new ClientHello will be sent using X25519 unless you want to lose customers. The client won't get an HRR back on the first try, the stuff just breaks (it's their bug, but it must be dealt with). But, if the DNS says it should work, it should be ok to fail there. The trustworthiness of this hint must also be weighed with ECH. So, if you're using SVCB with this idea and ECH, it seems pretty reasonable to me. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
