I respect your opinion here. I thought the behavior would be that clients actually didn’t negotiate much, so they wouldn’t downgrade.
But maybe that is unrealistic. thanks, Rob On Mon, Oct 24, 2022 at 19:28 Eric Rescorla <e...@rtfm.com> 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. 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://www.ietf.org/mailman/listinfo/tls >>> >>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
