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

[Steve <[e-mail]>]

Dear all,

There is a well-known Chinese saying: wise people learn from the mistakes
of others, while the unwise learn only from their own.

The working group would be much better served by learning from the
real-world vulnerabilities documented in “cited external references, CVEs
and publications” rather than having to rediscover those vulnerabilities
all over again.

Best regards,

Steve Luo

Thomas Fossati <[e-mail]> 于2026年9月22日周二 22:51写道：

> 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
> _______________________________________________
> Seat mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>