Return-Path: X-Original-To: seat@mail2.ietf.org Delivered-To: seat@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 1D46D120F9249 for ; Thu, 30 Jul 2026 04:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785411337; bh=f+3UDKOGo8B7LT8j3eLq0cYf48z5kQ4O+ozTmsHNvAk=; h=References:In-Reply-To:Reply-To:From:Date:Subject:To:Cc; b=AhnjWgwAInfFziKl6ChbUyIYUQ5NFF4+G+AnSu1R2R3PSTknZLI4NN6jPJn6/+Iu0 R8A84DoZjSliBizoEKO8hJHa56PRQ/drEx2QK0yA6KXFIDeB6g6sSO2fH2A9O4IRHL aEzuCky73Zu2CfXTaHuxKe7RgGkTJ0pG05pEmtJk= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9-VbofpksGh for ; Thu, 30 Jul 2026 04:35:36 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 2CC0F120F923E for ; Thu, 30 Jul 2026 04:35:36 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-84a4d8fd6ecso2225507b3a.1 for ; Thu, 30 Jul 2026 04:35:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1785411335; cv=none; d=google.com; s=arc-20260327; b=DSLT94knKLORgW8k8OdKsYmWiFRL9qxKMoUDVrVf3mtMslqbxFa7esqmVH/le5ndZ8 fUbbpQhqL55++0QK1CJ06K84sQ/1kC06VelT3z9wGPqxX2KILdIPmVKpw16A1B4FAgb9 fK7raGxbjhUyYmfTxyosxfpporaycMpqSxIkr0cAD4jWZqsLmSXW/xH0RjLEJJ9GGEht YZRJkU9c0FNtt7nPmS65rKKkCrqKMOizC0q0+GZvJUKvTL018KX7XO6//Bh2Gkrlw6nR ApmzFESrF+6CGj6fsk4L/cckfzpPeRK17gosa9HBXmDMJz+pCAIKT7b+L1LFua9f4xF/ Z/Jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:dkim-signature; bh=g1T2JJ6L00sbuf2mMh9MUJdD0FhcnmMi+nxg45a06iE=; fh=KwvdXt8FdG/tG+1+avIGuVI4z7A4xIoVcx0clDtACBw=; b=r93D+UV73aLkO6rpO3jfvMt7kKKu/iblloVrZQeunQSdjGWcpXgwv+4DEGyUe3XPxV Q6x1fPxnZXaumcQNYOTmQfJ/N1/UCjDkF2FZuWY48G396bV86pCd3H008GpVvl4caI8m G6BHNmc0D9b516jDIfN8VxtF/OqYp7xF9z5jQcbx440XKWbT1ypa9rqxEP1zC4B8Gr3q 6o1JZo3uFMZO0BJMeVWHB5UWWeffJ+mrEXEfxnzje/asr02Hy2fa8tv0jdbtCqXqWzzP VOSotnSGyzHB9F23GLikgQxA3chkGu/kmQym+HJ4h4wcCOoHxB5cS4FqlvpjOz38Aq+Q M3Iw==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785411335; x=1786016135; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:reply-to :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to:content-type; bh=g1T2JJ6L00sbuf2mMh9MUJdD0FhcnmMi+nxg45a06iE=; b=UPvhWX/d7dv5sDltxiKVENj54obKxrBDRraxXMdxatt0lhyqXAE2Y+Zbh9dRZDJxKb pwXWgif3t+P2+ZYR189PEBs2LCseOmI1sBCxYfKElTw6FYBtVrHEjSMdWM4h5B4EnTHf 0fL17QM9ZRvGrwrgq2BagGTB6CGROB1zUiciR8lcjt9882ebcREK0O5LIgX9aPmCX4qt RpHkR0Kkfy8KWKn9EAo+ACSODcuLM5zUUfiVhDKL+ART5h9+NTO+5JPBnXxTrgi9RwpB NgiagGE1jc85xXT+ytwFu6KyXI6UAaK0vcawNSnEoYMimKtbhGxkIh76WDqBNnq3dTL6 yIvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785411335; x=1786016135; h=content-type:cc:to:subject:message-id:date:from:reply-to :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=g1T2JJ6L00sbuf2mMh9MUJdD0FhcnmMi+nxg45a06iE=; b=gVxepWJ/QCTbcUCFpozMB+4w0vOCf8ER7DIs2f9eXrjH9qFD4eUJrGV4HPimWjhxBU v/6UxYruzVWVX9stvWmzpQmWE4RdlKYVfbCxDoNRCB3n9wHz8Jf+0h1fyh31cg5e3xbo QLzw3cmYEYLJdhT6QvEgxxYfSQF1pZK1t7Hf1cSKSBdiDX2xucJ+4CYYXzjFWuV9eFsF 81TWQJSm1KAryX2DXR9wKoiKcMkKz0L3SUkRXNlATJuCyzQF1ON+Gg0Rj0dMLzc3MEaD 8AIJpTGv/MokFrMI0mNypTHmkye7DXmUSuXErXH+sQrfH/iyXMGomsFTUueowsthHPJ9 2Qsg== X-Gm-Message-State: AOJu0YwDZmrPYTCYCLZRAwb5w7+k3r+vQOrYNjyT+oL8uC9yzKCfwUx7 FCtusFbIGXLBZNMRhIKA53y6WsCNsfJacMjFn2VYL+YRlZ+MlZ4ZF25WN7wsxh3rhR41j2sVQj5 bXi+WPpFo/GO7srIDlMbzUnhSjUe/70vEmQ== X-Gm-Gg: AR+sD12NsN98aofRnRWI8VHnVmEoHuLWTZ8VLlL3KgY/mSUgwp/hQ2f5H9cnEm9B4s2 qLcpgljT/CHojUcnr/3O65DIurOpvx04r2ek34dMW+WsYwyWFDQppXrWQzrQ0lN0LnV9k8QCE3y ywUOvkt+/Mm2tHkmfXd+VaAzbq9KQS8is0dtz2zXQiY6aEULPT1/t5kFz8zU4Rh0+nzrd6KOvNw kD4iVj3DB0wE1g/MvwuKLN+NVGbH7uRJqFb1Y7WaZIjoQIW0Jgt0+r5PQ9rz0WeNUy/9OQLdmc/ 4MqZ93It1KNVXsww+2QKq3t9g+2ApijH3gocYmyEOu+VzZuW0+DFi7stRcSUOWwWvbuSIU7wIg9 c X-Received: by 2002:a05:6a21:6196:b0:3bf:7081:9356 with SMTP id adf61e73a8af0-3c900758432mr2270607637.17.1785411335056; Thu, 30 Jul 2026 04:35:35 -0700 (PDT) MIME-Version: 1.0 References: <5f361893-bc32-4737-9578-fdb3ad7be3f9@tu-dresden.de> <9F03163D-B0F9-40DD-A4AB-69C151B872D6@aiven.io> <76b504ae-5692-4f31-a9d2-025974b12339@tu-dresden.de> <5fb42c5c-825b-472b-8455-ce893011ade5@tu-dresden.de> <9371184b-d6c1-44fa-b184-58811946ca55@tu-dresden.de> In-Reply-To: From: camilo ayerbe Date: Thu, 30 Jul 2026 13:35:17 +0200 X-Gm-Features: AUfX_mySJiXZFXSJyMCK07hvHlSSahsQy9hdkI6eT_nPLhoJGb4Gx9NRtgfntFY Message-ID: To: Songbo Bu Content-Type: multipart/alternative; boundary="0000000000006770840657d2781b" Message-ID-Hash: MWEVJMNLZYY25S64TJYSKKVXTYOTCXKQ X-Message-ID-Hash: MWEVJMNLZYY25S64TJYSKKVXTYOTCXKQ X-MailFrom: cayerbe@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: seat@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Reply-To: cayerbe@gmail.com Subject: =?utf-8?q?=5BSeat=5D_Re=3A_Comments_on_formal_analysis_of_relay_attacks_in_a?= =?utf-8?q?ttested_TLS_=28CVE-2026-33697=29?= List-Id: "Secure Evidence and Attestation Transport (SEAT) WG" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000006770840657d2781b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I'd like to add one point from an independent angle, and be clear about what it does and doesn't claim. For disclosure, I'm a co-author of TRIP , which is post-handshake, so I have a stake here. The CVE stands on its own =E2=80=94 the relay on the self-asserted-key bind= ers is real, and the response to it was right. From the timeline shared , I see that all the relevant stakeholders have acknowledged the relay attacks: - Cocos AI created the security advisory and acknowledged the formal analysis - CCC Intra-handshake attestation implementation has been declared vulnerable to relay attacks, and the repository has been archived. - Vulnerable intra-handshake draft draft-fossati-tls-attestation has been withdrawn by authors. - Edgeless Systems has created the security advisory and acknowledged the formal analysis. On the question the thread is actually asking =E2=80=94whether a hybrid int= ra+post design gives a security property post-handshake alone cannot =E2=80=94 I mo= deled the specified =C2=A75.1.1 (CA-backed TIK) of draft-fossati-seat-early-attestation-05 binder independently and landed where Usama and all others in the thread have: I couldn't find a property achievable in intra-handshake that a post-handshake step right after secure channel establishment couldn't also achieve. So I'm not offering a counter-example =E2=80=94 if anything, my look supports the "no separation" reading, and it leaves the open question where Songbo has put it: what does the intra-handshake version establish that post alone doesn't? If there is no such property, the complexity of intra-handshake is unnecessary, which is itself a security problem that I would like to avoid for my draft. I'd also agree the symbolic security analysis doesn't settle the computational questions raised here =E2=80=94 proof-of-possession for a key placed in rep= ort data, and cryptographic key-separation for reusing TLS-derived secrets both need more than symbolic security analysis. I'd leave those open. The dimension I'd add is *continuity*, as an architectural requirement rather than a formal property. An intra-handshake binder attests once, at setup; for use cases where the peer's measured state can change over the life of the connection, that single attestation goes stale, and only post-handshake =E2=80=94 repeated or interval =E2=80=94 attestation keeps i= t fresh. This is the case TRIP is built around, and a one-shot intra-handshake binder structurally can't provide it. I raise it because it points the same way as the thread: post-handshake is the load-bearing mechanism, and for these use cases it isn't optional. Thanks, Camilo On Thu, Jul 30, 2026 at 11:48=E2=80=AFAM Songbo Bu = wrote: > Hi all, > > I agree with the clarifications in Usama's message. The question is > not whether a modified construction can satisfy selected correlation > properties under its own assumptions. My question was whether a hybrid > intra- and post-handshake design establishes a specific security > property that post-handshake attestation alone cannot establish. > > The public artifact separates three correlation goals: Evidence with > the DH shared secret (G1), the client handshake traffic key (G2), and > the client application traffic key (G3). It shows that its proposed > intra-handshake construction establishes G1 and G2 but not G3. The > artifact does not model a hybrid design against a post-handshake-only > baseline, so it does not demonstrate a hybrid-over-post separation. > > For that reason, I think a claimed counter-example should state: > > 1. the exact property satisfied by hybrid but not post-only; > 2. the identical adversary, trust, and deployment assumptions under > which both are compared; > 3. the exact statement in Section 9 that the result contradicts; and > 4. the endpoint events and correspondence query used to establish the > separation. > > Without that separation, changing the construction may still produce a > useful design, but it does not answer the question I posed. It also > leaves the additional intra-handshake machinery=E2=80=94Evidence availabi= lity > during the handshake, interaction with transcript and key state, new > failure paths, and implementation burden=E2=80=94without a demonstrated > security benefit over post-handshake attestation alone. > > I also agree that two questions should be evaluated separately from > symbolic equality. Placing an infrastructure public key or identity in > signed report data does not by itself prove possession of the > corresponding private key. Reusing TLS-derived traffic keys for > another purpose also needs an explicit key-separation and > computational-security justification. These questions are not settled > merely because a symbolic model can express an equality. > > This does not rule out operational reasons for a hybrid design. It > asks that operational motivation be separated from the claimed > security property, and that the latter be stated in a form that can be > formally verified. ProVerif code is never wired up in real > implementations. > > On Tue, 28 Jul 2026 15:37:02 -0600, Nathanael Ritz > wrote: > > Top posting. It appears I have been asked to set aside falsifiable > formal analysis effort or to suggest that such work is itself > unfalsifiable. While that may or may not be true, I believe this thread h= as > truly run its course. > > > > Sincerely, > > > > Nathanael > > > > On Tue, 28 Jul 2026 at 14:37, Muhammad Usama Sardar < > muhammad_usama.sardar@tu-dresden.de> wrote: > > > > Hi Nathanael, > > > > Markus kindly clarified what he would like to see in more detail. > > Could you please do the same to help keep this discussion more > > focused? Here is my understanding of the points where you > > disagree: > > > > - While the paper [6] claims it 'may not be possible' to achieve > > level 3 binding in intra-handshake attestation, you believe it > > is possible. Setting aside what you model and prove is correct > > or not, I don't see how this contradicts the claim 'may not be > > possible' in the paper. > > > > - We haven't yet seen a property that the hybrid construction > > > (intra- + post-handshake attestation) can satisfy, but > > post-handshake attestation alone cannot satisfy, unless > > you are implicitly implying that level-3 binding cannot be > > achieved by post-handshake attestation. Please clarify > > explicitly. > > > > Is there something I have missed? As mentioned before to Markus, > > I believe it is much more organized to have them answered in > > detailed technical report. So more important than the discussion > > below is the correction/addition/edits in above statements. > > > > Also, I believe it will be more constructive to respond point by > > point to [5] where you disagree, so we can do further working to > > share with the WG/RG. > > > > We will then work on it and share with the WG/RG. > > > > On 28.07.26 20:51, Nathanael Ritz > > wrote: > > > > On Tue, 28 Jul 2026 at > > 10:00, Muhammad Usama Sardar > > wrote: > > > > This does not address any of the questions in [5] > > where your working was shown to be not correct, and > > these inaccuracies still remain here too. > > > > [NR}: I disagree, but the authors are welcome to cite > > my work and my words directly in relationship to any > > questions that are, in their opinion, left unanswered so > > that I can address them directly rather than guessing. > > > > For example, our responses to your #2 in [5]. > > > > For clarity, nothing has changed in the key schedule > > of TLS 1.3 for quite long time (I think draft-20 which > > became RFC8446). Saying that RFC9846 is "new work" for > > key schedule is almost surely wrong. Maybe Ekr can > > confirm. > > > > [NR]: If it is being stated that I am suggesting > > RFC9846 includes 'new work for key schedule', please quote > > me directly, as I am currently unclear to what context and > > statements are being referenced to right now. > > > > Thanks for clarifying. 'non-conformant Key Schedule' and then > > mention of RFC 9846 =C2=A77.5 was unclear for #2 in [5]; it has stayed > > the same for pretty much a decade. We believe that both points in > > your #2 about key schedule are not valid and we justified it > > technically in [5], to which we have seen no response. > > > > Best regards, > > > > Usama, Slava, and Jean-Marie > > > > [5] > https://mailarchive.ietf.org/arch/msg/seat/dKVqaL8RJSQLonIEmtzrDYEXEAU/ > > > > [6] > https://www.researchgate.net/publication/408219182_Intra-handshakefail_CV= E-2026-33697_High-severity_CVE_in_Attested_TLS > > _______________________________________________ > Seat mailing list -- seat@ietf.org > To unsubscribe send an email to seat-leave@ietf.org > --0000000000006770840657d2781b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi all,

I'd like to add one point from an independent angle, and be cl= ear about what it does and doesn't claim. For disclosure, I'm a co-= author of TRIP, which is post-handshake, so I have = a stake here.


The CVE stands on its own =E2=80=94 the rel= ay on the self-asserted-key binders is real, and the response to it was rig= ht. From the timeline = shared, I see that all the relevant stakeholders have acknow= ledged the relay attacks:=C2=A0



On the = question the thread is actually asking =E2=80=94whether a hybrid intra+post= design gives a security property post-handshake alone cannot =E2=80=94 I m= odeled the specified =C2=A75.1.1 (CA-backed TIK) of draft-fossati-seat-earl= y-attestation-05 binder independently and landed where Usama and all others= in the thread have: I couldn't find a property achievable in intra-han= dshake that a post-handshake step right after secure channel establishment = couldn't also achieve. So I'm not offering a counter-example =E2=80= =94 if anything, my look supports the "no separation" reading, an= d it leaves the open question where Songbo has put it: what does the intra-= handshake version establish that post alone doesn't? If there is no suc= h property, the complexity of intra-handshake is unnecessary, which is itse= lf a security problem that I would like to avoid for my draft. I'd also= agree the symbolic security analysis doesn't settle the computational = questions raised here =E2=80=94 proof-of-possession for a key placed in rep= ort data, and cryptographic key-separation for reusing TLS-derived secrets = both need more than symbolic security analysis. I'd leave those open.


The dimension I'd add is continuity, as an arch= itectural requirement rather than a formal property. An intra-handshake bin= der attests once, at setup; for use cases where the peer's measured sta= te can change over the life of the connection, that single attestation goes= stale, and only post-handshake =E2=80=94 repeated or interval =E2=80=94 at= testation keeps it fresh. This is the case TRIP is built around, and a one-= shot intra-handshake binder structurally can't provide it. I raise it b= ecause it points the same way as the thread: post-handshake is the load-bea= ring mechanism, and for these use cases it isn't optional.


Thanks, Camilo



On Thu, Jul 30, 2026 at= 11:48=E2=80=AFAM Songbo Bu <bluedognull@gmail.com> wrote:
Hi all,

I agree with the clarifications in Usama's message. The question is
not whether a modified construction can satisfy selected correlation
properties under its own assumptions. My question was whether a hybrid
intra- and post-handshake design establishes a specific security
property that post-handshake attestation alone cannot establish.

The public artifact separates three correlation goals: Evidence with
the DH shared secret (G1), the client handshake traffic key (G2), and
the client application traffic key (G3). It shows that its proposed
intra-handshake construction establishes G1 and G2 but not G3. The
artifact does not model a hybrid design against a post-handshake-only
baseline, so it does not demonstrate a hybrid-over-post separation.

For that reason, I think a claimed counter-example should state:

1. the exact property satisfied by hybrid but not post-only;
2. the identical adversary, trust, and deployment assumptions under
which both are compared;
3. the exact statement in Section 9 that the result contradicts; and
4. the endpoint events and correspondence query used to establish the
separation.

Without that separation, changing the construction may still produce a
useful design, but it does not answer the question I posed. It also
leaves the additional intra-handshake machinery=E2=80=94Evidence availabili= ty
during the handshake, interaction with transcript and key state, new
failure paths, and implementation burden=E2=80=94without a demonstrated
security benefit over post-handshake attestation alone.

I also agree that two questions should be evaluated separately from
symbolic equality. Placing an infrastructure public key or identity in
signed report data does not by itself prove possession of the
corresponding private key. Reusing TLS-derived traffic keys for
another purpose also needs an explicit key-separation and
computational-security justification. These questions are not settled
merely because a symbolic model can express an equality.

This does not rule out operational reasons for a hybrid design. It
asks that operational motivation be separated from the claimed
security property, and that the latter be stated in a form that can be
formally verified. ProVerif code is never wired up in real
implementations.

On Tue, 28 Jul 2026 15:37:02 -0600, Nathanael Ritz <nathanritz@gmail.com> wrote: > Top posting. It appears I have been asked to set aside falsifiable for= mal analysis effort or to suggest that such work is itself unfalsifiable. W= hile that may or may not be true, I believe this thread has truly run its c= ourse.
>
> Sincerely,
>
> Nathanael
>
> On Tue, 28 Jul 2026 at 14:37, Muhammad Usama Sardar <muhammad_usama.s= ardar@tu-dresden.de> wrote:
>
> Hi Nathanael,
>
> Markus kindly clarified what he would like to see in more detail.
> Could you please do the same to help keep this discussion more
> focused? Here is my understanding of the points where you
> disagree:
>
> - While the paper [6] claims it 'may not be possible' to achie= ve
> level 3 binding in intra-handshake attestation, you believe it
> is possible. Setting aside what you model and prove is correct
> or not, I don't see how this contradicts the claim 'may not be=
> possible' in the paper.
>
> - We haven't yet seen a property that the hybrid construction

> (intra- + post-handshake attestation) can satisfy, but
> post-handshake attestation alone cannot satisfy, unless
> you are implicitly implying that level-3 binding cannot be
> achieved by post-handshake attestation. Please clarify
> explicitly.
>
> Is there something I have missed? As mentioned before to Markus,
> I believe it is much more organized to have them answered in
> detailed technical report. So more important than the discussion
> below is the correction/addition/edits in above statements.
>
> Also, I believe it will be more constructive to respond point by
> point to [5] where you disagree, so we can do further working to
> share with the WG/RG.
>
> We will then work on it and share with the WG/RG.
>
> On 28.07.26 20:51, Nathanael Ritz
> wrote:
>
> On Tue, 28 Jul 2026 at
> 10:00, Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de= >
> wrote:
>
> This does not address any of the questions in [5]
> where your working was shown to be not correct, and
> these inaccuracies still remain here too.
>
> [NR}: I disagree, but the authors are welcome to cite
> my work and my words directly in relationship to any
> questions that are, in their opinion, left unanswered so
> that I can address them directly rather than guessing.
>
> For example, our responses to your #2 in [5].
>
> For clarity, nothing has changed in the key schedule
> of TLS 1.3 for quite long time (I think draft-20 which
> became RFC8446). Saying that RFC9846 is "new work" for
> key schedule is almost surely wrong. Maybe Ekr can
> confirm.
>
> [NR]: If it is being stated that I am suggesting
> RFC9846 includes 'new work for key schedule', please quote
> me directly, as I am currently unclear to what context and
> statements are being referenced to right now.
>
> Thanks for clarifying. 'non-conformant Key Schedule' and then<= br> > mention of RFC 9846 =C2=A77.5 was unclear for #2 in [5]; it has stayed=
> the same for pretty much a decade. We believe that both points in
> your #2 about key schedule are not valid and we justified it
> technically in [5], to which we have seen no response.
>
> Best regards,
>
> Usama, Slava, and Jean-Marie
>
> [5] https://mailarchive.= ietf.org/arch/msg/seat/dKVqaL8RJSQLonIEmtzrDYEXEAU/
>
> [6] https://www.researchgate.net/publication/408219= 182_Intra-handshakefail_CVE-2026-33697_High-severity_CVE_in_Attested_TLS

_______________________________________________
Seat mailing list -- sea= t@ietf.org
To unsubscribe send an email to seat-leave@ietf.org
--0000000000006770840657d2781b--