On 30.05.25 18:08, Eric Rescorla wrote:
ok fine, but the least we should do is to make PSKBinderEntry explicit. I have submitted a PR [1]. Please check.> Issue 2: "Binder Finished Key"I would appreciate an explicit entry in Table 2, rather than burying it deep in Section 4.2.11.2. Something like: Mode = PSK | Handshake Context = ... | Base Key = binder_key I don't think this change is indicated. It is not a Finished key.
[1] https://github.com/tlswg/tls13-spec/pull/1392
> --- > > Issue 4: Full key derivation schedule: > > TL;DR: Please add full key derivation schedule in specifications in RFC8446bis. > > Details: > > The text in section 7.1 says > > > This produces a full key derivation schedule shown in the diagram below. > > The figure, however, by no means is anything close to a full key > schedule. It shows only the first stage of keys. Seems like it would > be very beneficial if at least the Appendix of RFC8446bis includes a > full key derivation schedule. Right now, the key schedule is > scattered around in sections 7.1, 7.3, 7.5, 4.4 and 4.4.4. This diagram is already quite large, so I fear it would be a lot of work to produce something that was readable. I agree it's not helpful to say "full" here, and I'd welcome some revised text.Happy to propose revised text but without such a complete diagram, I don't know how we can have consensus on what is a "full" key schedule. For example, how can I be sure that I have not missed a key buried somewhere deep in the specs? How can I be sure that the "reference" key schedule -- that I am using to validate the key schedule -- is correct and complete?Well "full key schedule" isn't used otherwise, so I'm not sure we need to have a definition for this.
I am not asking for a definition per se. See below.
Are you saying that there is some lack of clarity on what keys are generated, or merely thatyou think it requires a close read to find it.
Well, I may be a careless reader but many experts who have several years of work on TLS have got it wrong too. In particular, the level of detail in ECH formal analysis [3] is really amazing, but they have got the key schedule wrong too. I will share some statistics of my preliminary working:
* The formal model "reftls" [2] has missed at least 6 keys and has generated at least 12 keys incorrectly. * The formal model of ECH [3] has missed at least 5 keys and has generated at least 12 keys incorrectly. * The formal model of ECH [3] has invented a new key in the key schedule, namely "client_fkad" [4] which they claim to be modeling "[sender]_finished_key" (in addition to the two finished keys). I don't find anything like this in the TLS or ECH specs. So where is this coming from?I agree with you that it is perhaps a lot of work to have a full key schedule diagram and to still keep it readable. But I haven't received a satisfactory answer to my question, namely how do I ensure that my "reference key schedule" is correct and complete? Who other than TLS WG can provide such a "reference key schedule"? It is not even clear how many keys are there in the full key schedule.
I am not insisting on a diagram. It could be in text form, e.g., a complete list of *all keys* as a starting point. It could be in the Appendix.
I will happily propose something as a starting point. To my understanding, it would be table 3 in [5] + PSKBinderEntry + [sender]_write_iv. Is there any other key?
Usama[2] https://github.com/Inria-Prosecco/reftls/blob/master/pv/tls13-draft20-only.pv
[3] https://gitlab.inria.fr/chevalvi/echo_tls[4] https://gitlab.inria.fr/chevalvi/echo_tls/-/blob/9fd6b2a0523087d41ba480c6180b9da92833ca50/libraries/key_schedule.pvl#L95
[5] https://ieeexplore.ieee.org/document/10752524
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
