In TLS <= 1.2, the client and server agree on the (EC)DHE group to use for key exchange by negotiating it (at the cost of a round-trip).
In TLS 1.3, the client tries to guess what (EC)DHE group(s) the server might support and sends key share(s) accordingly (saving a round-trip). When a TLS 1.3 client fails to guess correctly, HRR message triggers handshake restart, this time with no guessing involved. This failure to guess is undesirable, but luckily not very frequent (as long as TLS implementers choose to prioritize roughly the same sets of (EC)DHE groups). The introduction of PQ algorithms and hybrid key exchange will add options and at the same time may reduce the number of different key shares the TLS client is willing/able to generate and send. It is possible that the HRR message flow might become more common during the PQC transition. How can we possibly deprecate HRR (without deprecating TLS 1.3)? (It's also not clear to me how we would get rid of HRR in a future TLS version, without removing algorithm options, adding round-trips, or relying on some out-of-band signals.) Cheers, Andrei -----Original Message----- From: TLS <tls-boun...@ietf.org> On Behalf Of Stephen Farrell Sent: Monday, October 24, 2022 7:57 PM To: Eric Rescorla <e...@rtfm.com>; Rob Sayre <say...@gmail.com> Cc: tls@ietf.org Subject: [EXTERNAL] Re: [TLS] Published RFC 8446bis -05 Hiya, On 25/10/2022 03:27, Eric Rescorla wrote: > On Mon, Oct 24, 2022 at 7:17 PM Rob Sayre <say...@gmail.com> wrote: > >> Is removing HRR on the table? >> > > No, I don't think so. It performs an important function. Is there any public info as to how often HRR happens? (Sorry if that's well known, but it's not well known to me:-) Were that rare enough, I'd hope it'd be a thing where we could reach consensus for deprecation. If it's not yet sufficiently rare, it might be worth considering if we could change something to make HRR less likely. Cheers, S. > Moreover, the intent of this revision to TLS 1.3 was to clarify 8446, > and this would be a major (and breaking!) change. > > > >> Maybe just opening a new socket would suffice? >> > > I don't see that this would help. > > 1. It would not be clear to the client what it had to do to provide an > acceptable CH. 2. Without some sort of HRR-like coupling, it would > allow downgrade attacks. > > -Ekr > > > >> thanks, Rob >> >> On Mon, Oct 24, 2022 at 13:08 Eric Rescorla <e...@rtfm.com> wrote: >> >>> Hi Folks, >>> >>> I have just published draft-ietf-tls-rfc8446bis-05, with the >>> following changes: >>> >>> * Update the extension table (Issue 1241) * Clarify user_canceled >>> (Issue 1208) * Clarify 0-RTT cache side channels (Issue 1225) * >>> Require that message reinjection be done with the current hash. >>> Potentially a clarification and potentially a wire format change >>> depending on previous interpretation (Issue 1227) >>> >>> I landed a few current PRs without review. If people think I handled >>> these incorrectly or mis-merged, please flag that. >>> >>> This includes most of the outstanding issues and PRs. The following >>> remain: >>> >>> PRS 1275 -- Clarifying unsolicited extensions [Waiting for review >>> from Kaduk] 1270 -- The impact of excessive key updates [Working on >>> text with MT] 1269 -- A new error for invalid tickets [see below] >>> 1231 -- Update in light of RFC 8773 [I missed this, but will get to >>> it on my next pass] >>> >>> >>> SUBSTANTIVE ISSUES 1223, 1224 -- Revising the HRR rules 1278 -- >>> There are no entries in the table for which TLS 1.3 messages token >>> binding goes in. >>> >>> >>> As preview of our discussion in London. >>> >>> I believe I can handle 1275, 1270, and 1231 at the editorial level. >>> >>> I believe we should not land 1269. As noted in the issue there is >>> already an unknown_psk_identity, which captures this. I propose to >>> close this issue. >>> >>> We need to agree on what appears in the table for token binding. >>> I think this is mechanical. MT? DavidBen? Andrei? >>> >>> >>> This leaves us with 1223 and 1224. I agree that the HRR semantics >>> are a little confusing, but we don't seem to be making much progress >>> on revising them and given that 8446 is already out, I think we >>> should just publish this revision and then if people get energy to >>> address this issue we can do so later. >>> >>> >>> -Ekr >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ TLS mailing list >>> TLS@ietf.org >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww >>> w.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C01%7CAndrei.Popo >>> v%40microsoft.com%7C05e3b7f3afc84fe347bf08dab634b33c%7C72f988bf86f14 >>> 1af91ab2d7cd011db47%7C1%7C0%7C638022634746453365%7CUnknown%7CTWFpbGZ >>> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >>> %3D%7C3000%7C%7C%7C&sdata=xWSwOGLU1Nd6jQvU7uQ0sEwGldTf8tz4EwO%2B >>> HkCS6UQ%3D&reserved=0 >>> >> > > > _______________________________________________ TLS mailing list > TLS@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C01%7CAndrei.Popov%40 > microsoft.com%7C05e3b7f3afc84fe347bf08dab634b33c%7C72f988bf86f141af91a > b2d7cd011db47%7C1%7C0%7C638022634746453365%7CUnknown%7CTWFpbGZsb3d8eyJ > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000 > %7C%7C%7C&sdata=xWSwOGLU1Nd6jQvU7uQ0sEwGldTf8tz4EwO%2BHkCS6UQ%3D&a > mp;reserved=0 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
