On Mon, Jun 2, 2025 at 11:56 AM Muhammad Usama Sardar <
muhammad_usama.sar...@tu-dresden.de> wrote:

>
> On 02.06.25 19:52, Eric Rescorla wrote:
>
> This is a minor revision to RFC 8446, which has already been published.
> It includes useful clarifications and we'd like to get it out the door.
>
> Are you trying to say that clarifications on key schedule are not useful?
> Specially, given that many people have got it wrong?
>

I'm saying that it's *already* useful, has been approved by the IESG,
and so I'd like to get it out the door. The standard here is whether this
change is so important we should hold up the whole spec.



> On Mon, Jun 2, 2025 at 10:35 AM Muhammad Usama Sardar <
> muhammad_usama.sar...@tu-dresden.de> wrote:
>
>>
>> On 30.05.25 18:08, Eric Rescorla wrote:
>>
>>
>>
>>> > 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.
>>
>> ok fine, but the least we should do is to make PSKBinderEntry explicit. I
>> have submitted a PR [1]. Please check.
>>
>> [1] https://github.com/tlswg/tls13-spec/pull/1392
>>
> This does not appear to be correct. But more generally, I'm just not
> following
> why you think this is necessary. The text says:
>
>    The PskBinderEntry is computed in the same way as the Finished
>    message (Section 4.4.4) but with the BaseKey being the binder_key
>    derived via the key schedule from the corresponding PSK which is
>    being offered (see Section 7.1).
>
> And then 4.4.4 provides the expansion:
>
>    finished_key =
>        HKDF-Expand-Label(BaseKey, "finished", "", Hash.length)
>
> Why is this confusing?
>
> The thing that I am really struggling to understand is that the key for
> PskBinderEntry is computed the same way as finished key but then you said
> earlier that it is "not technically a Finished key" [1]. So what is the
> definition of a Finished key and why does the key for PskBinderEntry not
> fulfill that criteria (while being computed in exactly same way)?
>
> [1] https://mailarchive.ietf.org/arch/msg/tls/Ho98JDz06Tuz_bQZPMNdgIs3Q5A/
>
It's not a Finished key because it's not used to compute the Finished
message.

I agree that it's a bit awkward, like everything else about PSK Binders,
but I
don't think rebranding it as a Finished key would be helpful, especially as
whether
we do so or not has no impact on the protocol, which we're not changing.

-Ekr
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Reply via email to