Hi! Thanks all to those who participated! We have consensus to land these two
PRs; #1343 got tweaked during this call.
ekr - merge when you get a chance.
spt
> On Jun 12, 2024, at 16:23, Sean Turner wrote:
>
> Hi! Just reminder to get any concerns about merging these in by 17 June 2024.
>
>
Hi! Just reminder to get any concerns about merging these in by 17 June 2024.
spt
> On Jun 3, 2024, at 11:38, Sean Turner wrote:
>
> Since draft-ietf-tls-rfc8446bis last completed WGLC, two PRs have been
> submitted (and discussed) that include changes to normative language:
>
> - #1343:
ould make the requirement more clear, and avoid enforcement
> of a requirement that can’t be strictly followed.
>
>
>
> *From:* David Benjamin
> *Sent:* Thursday, June 6, 2024 5:48 PM
> *To:* Kyle Nekritz
> *Cc:* Sean Turner ; TLS List
> *Subject:* Re: [TLS]Re: Consensus
make the requirement more clear, and avoid enforcement of a
requirement that can’t be strictly followed.
From: David Benjamin
Sent: Thursday, June 6, 2024 5:48 PM
To: Kyle Nekritz
Cc: Sean Turner ; TLS List
Subject: Re: [TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345
Regardin
Regarding 1343, the PR is a rule on the sender, not the receiver. After
all, it says "The sender MUST NOT". It is not a rule on the receiver.
We have interop problems *today* when one side sends too many KeyUpdates,
triggered by data received. The PR does not ask receivers to enforce
stuff, but
I object to 1343 because I don't think it can be implemented without risking
interop problems. There is nothing tying a KeyUpdate response to the KeyUpdate
that requested it, or distinguishing it from an unrelated KeyUpdate. As an
example of how this can cause practical problems, say we have
Gentle reminder about these two PRs. I should note there are now others.
spt
> On Jun 3, 2024, at 11:38, Sean Turner wrote:
>
> Since draft-ietf-tls-rfc8446bis last completed WGLC, two PRs have been
> submitted (and discussed) that include changes to normative language:
>
> - #1343: Forbid
