On Sun, Nov 17, 2024 at 12:05 PM Ilari Liusvaara <ilariliusva...@welho.com>
wrote:
> 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.
>
I was thinking that, until the server decrypts epoch 4, the server will
already naturally be retaining epoch 3 for application data anyway. And
once the server decrypts epoch 4, it knows the client has received the ACK
and it is safe to stop responding to those retransmits. I.e. we're not
going out of our way to retain epoch 3, just following the natural
progression of epochs. The KeyUpdate rule then generalizes: You retain
epoch N-1 until you receive epoch N. Once you receive epoch N, you can
freely drop N-1.
> 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.
>
Having the protocol observe the KeyUpdate rule definitely helps, but a
connection may last quite a while before a KeyUpdate. (If there is one at
all; as you note, KeyUpdates aren't particularly well-exercised[*].) The
server needs to retain epoch 2 until it guesses that the ACK probably got
through. Or maybe it just gives up and special-cases and retains epoch 2
indefinitely until a KeyUpdate, I dunno. Seems kind of silly.
[*] Early on the days of TLS 1.3, we tried to make Chrome trigger a
KeyUpdate shortly after the handshake. We immediately hit compatibility
issues because some servers could not handle it. In hindsight, doing that
at the very start would have been prudent, before TLS 1.3 was deployed at
all, but sadly I don't have a time machine.
> > > - 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
>
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
