On Sun, Nov 17, 2024 at 07:54:17AM -0500, David Benjamin wrote:
> On Sat, Nov 16, 2024 at 10:40 AM Ilari Liusvaara <ilariliusva...@welho.com>
> wrote:
>
> > On Wed, Nov 13, 2024 at 01:39:43PM -0500, David Benjamin wrote:
>
> A thought: This is now a protocol change, but what if we defined a "oops"
> extension that simply adds a dummy post-Finished handshake message that
> protrudes into epoch 3? I.e., if negotiated, the client and server flights
> actually look like this:
>
> CH -->
> <-- SH {EE..Finished} [Oops]
> {Finished} [Oops] -->
> <-- [ACK]
>
> I think if you combine that with the "ACKing epoch 3 implicitly ACKs all of
> epoch 2" rule, this problem might be resolved? All retransmits by the
> client are now guaranteed to contain at least one byte of Oops, because a
> fully-acked Oops implies an acked Finished. That means the server need only
> retain epoch 3, because as long as it can ACK the Oops, the client will get
> the message.
I don't think retaining epoch 3 is improvement over retaining epoch 2.
However, I think that the requirement that all prior flights must be
complete before stepping epoch helps here: It allows the server to drop
epoch 2 upon decrypting epoch 4 record. Even without the extra message.
> > - Single epoch, multiple prepare for next epoch messages.
> >
> > What does it mean for a single epoch to contain multiple messages that
> > prepare for the next epoch? Does that prepare one epoch or multiple
> > epochs? Doing multiple might cause issues with epoch reconstruction.
> >
> > AFAICT, sending multiple KeyUpdates in one epoch is not forbidden (the
> > spec requires ACK, not actual epoch bump in between).
> >
>
> I believe it's forbidden by this text. But I suspect this was on accident
> because it's not just to facilitate epoch reconstruction:
>
> > In order to facilitate epoch reconstruction (Section 4.2.2),
> implementations MUST NOT send records with the new keys or send a new
> KeyUpdate until the previous KeyUpdate has been acknowledged (this avoids
> having too many epochs in active use).
> https://www.rfc-editor.org/rfc/rfc9147.html#section-8-1
I found that text, but I think it still allows peer to send KeyUpdate,
get ACK, and then send another KeyUpdate in the same epoch...
> In my attempt to fix the other KeyUpdate brokenness, I said that nothing
> may follow a KeyUpdate in that epoch, which I think captures this a bit
> more directly. I think that works? Except...
> https://www.rfc-editor.org/errata/eid8047
Yeah, that should do it (modulo other KeyUpdate-like messages).
> > And in future extensions, there might be more message types that prepare
> > epoch bumps (e.g., some Extended Key Update messages). The interactions
> > between those (and regular KeyUpdate) might not be simple.
> >
> > I think there should be requirement that in each epoch, there is at
> > most one message that prepares for the next epoch, and that all
> > application data epoch except the last have exactly one.
> >
> > And with restriction that retransmissions must occur on the same epoch
> > (why is that there for post-handshake messages?), the message that
> > prepares for the next epoch must always be the last in its flight.
> >
>
> Extended Key Update is potentially extra fun because it's a multi-flight
> transaction. What happens if you start an EKU flow but then, partway
> through it, the peer sends a plain KeyUpdate? What if one side starts an
> EKU flow and, at the same time, the other side sends KeyUpdate with
> key_update_requested? Will the EKU-sending peer know not to confuse itself?
> Or maybe we can design EKU such that it still works out, because the next
> epoch hasn't been prepared yet? EKU doesn't exist yet, but something we'll
> have to reason through when we get there.
EKU flow is defined to block ordinary KeyUpdate. So ordinary KeyUpdate
partway through is not allowed. The crossed case will not trigger
reciprocal KeyUpdate (the EKU transaction will update keys).
However, that restriction might not be necessary. I can come up with
design that should work as long as there can not be multiple prepare
for next epoch in a single epoch, nor multi-flight deadlocks.
Basic idea is to have 2nd and 3rd flights prepare for epoch change
(update send keys in TLS), and sender of 2nd flight save the KEM shared
secret for processing the received 3rd flight. Then there is 4th message
for case where the peer lost the initiator election.
-Ilari
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
