[Seat] Re: Guidance text for draft-ietf-seat-use-cases

[Thomas Fossati <[e-mail]>]

On Tue, Sep 22, 2026 at 4:04 PM Chengxin Huang <[e-mail]> wrote:
>
> Dear Nathanael,
>
> Thank you for the clarification. I agree that reusing HKDF-Expand-Label to produce binding values does not, by itself, modify the TLS key schedule. My earlier statement about Section 5.1.1 was too broad.
>
> Regarding Haowen's text, requiring a shared-secret input does constrain the design, even without specifying which secret. However, whether that constraint is necessary is a separate security question; the key-schedule clarification alone does not resolve it.
>
> Section 3.3.2 of use-cases-01 already states that matching the correct connection binder alone does not establish the association between the evidenced Target Environment and the TLS peer. Could you point to the mandatory checks in early-attestation-07 that establish this association, and explain how they satisfy that requirement without a shared-secret input to the binder? That would help us evaluate the proposed guidance against a concrete security requirement.

Section 8.1.1 of early-07 explains how the proposed binder prevents
misbinding attempts, even without using an explicit shared secret in
the construction.
Please take a look.

-- 
Thomas