On Wed, Jul 08, 2026 at 04:21:22PM -0400, David Benjamin wrote:
> I think you're interpreting it right. If the cipher suite does not exactly
> match what you end up negotiating, you cannot accept early data.
>
> > With the 0-RTT keys independent of the 1-RTT keys, why must the full
> > 0-RTT cipher suite match the 1-RTT cipher suite that comes into effect
> > only later?
>
> The unhelpful answer is "because the spec said so". But that is unhelpful.
> :-)
Thanks. Given recent discussion around SSLKEYLOGFILE, I guess I might
note that if the early data algorithm (not just the key) could be
different from the 1-RTT algorithm, then the SSLKEYLOGFILE would fail to
record that information...
> More helpfully, I think the spec's choice is the right one. You're right
> that we *could* have defined it so that the cipher suite changes across
> 0-RTT and 1-RTT and it would (I think?) have been well-defined
> self-consistent at the TLS layer.
Yes, that's the motivation for the question.
> Likewise, we also *could* have said that ALPNs change at this
> transition or whatever else. The question is whether
> these are good semantics to present to the application layer.
Well, the ALPN changing is a very different sort of problem.
> *If* we said that the cipher suite changes, it would mean that the
> connection properties change partway through the lifetime of the
> connection.
>
> This breaks an invariant[*] of a TLS connection's lifecycle:
> 1. First you set up the connection.
> 2. Now connection properties are set and you can query ALPN, version,
> cipher suite, certificate, whatever else.
> 3. Read and write data as you wish.
Or the library could simply hide the 0-RTT cipher from the application
and report the 1-RTT cipher consistently, but I guess that's not the
sort of thing that folks would be comfortable with, and in any case the
specification requires the cipher to not change.
> The cipher suite, sure, is less dire. But maybe your protocol has the
> client send something cipher-suite-dependent and then the server responds
> with something cipher-suite-dependent.
Well, the 0-RTT cipher is not nearly as important as the subsequent
1-RTT cipher, it is for low-value data that might be subject to replay,
say a DNS query, with the response in a propertly secured 1-RTT payload.
So the "more relevant" cipher to report is the 1-RTT cipher, and the
0-RTT cipher is rather secondary. Speaking hypothetically, of course.
Since I won't actually ignore the specification.
> Since you already have to make predictions on other fields like ALPN, doing
> that for cipher suites seems not much of a price to pay for this sanity.
Well, the ALPN is much less likely to be mispredicted. Especially when
it isn't one of multiple HTTP flavours, but something else entirely.
> Plus the prediction is easy for resumption: it's the cipher suite you got
> on the original connection. I recognize that's not true for PSKs, but I'll
> note that if your PSKs are longer-lived and broader-scoped than resumption
> secrets doing 0-RTT (no forward secrecy) with them is probably not the best
> plan anyway.
So in particular, I expect that "imported" RFC9258 PSKs, that are by
design cipher (and KDF) agnostic (polymorphic), should NOT be used
with 0-RTT. An RFC9258 PSK is not a prediction of the cipher, and
which imported KDF happens to land first on the wire is not even
something that the application providing the input external PSK
should depend on.
Would you concur that an RFC9258 "ipsk" landing in slot 0 should not
be used for 0-RTT? Even if the client tries to send early data with
an "ipsk", I'm inclined to unconditionally decline that early data.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
