Re: [TLS] Published RFC 8446bis -05

Stephen Farrell Mon, 24 Oct 2022 19:57:43 -0700


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://www.ietf.org/mailman/listinfo/tls

OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Published RFC 8446bis -05

Reply via email to