MIME-Version: 1.0
References: 
 <177750265590.432348.3146191093263172762@dt-datatracker-b45949c58-t72jx>
 <0388f4fe-54e0-41b2-a520-3a2eb27f642a@tu-dresden.de>
 <D5D9352B-E4DD-4596-B4A3-F2F88EE75275@writerslogic.com>
In-Reply-To: <D5D9352B-E4DD-4596-B4A3-F2F88EE75275@writerslogic.com>
From: Nathanael Ritz <nathanritz@gmail.com>
Date: Thu, 7 May 2026 21:24:12 -0600
Message-ID: 
 <CAHxYnaOT+oD8vYbzCg_EYtDhEvsD71uxgRwfajCB96846Atsvw@mail.gmail.com>
To: David Condrey <david=40writerslogic.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ec4dee065145ee2e"
Message-ID-Hash: DFT67MOWKTVMZAKSE5BKN2MCBU7EDDOJ
CC: "rats@ietf.org" <rats@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BRats=5D_Re=3A_New_Version_Notification_for_draft-sardar-rats-se?=
	=?utf-8?q?c-cons-03=2Etxt?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/rats/rVsKG4MDPP_JTxvTYCBo-YNRPbU>

--000000000000ec4dee065145ee2e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi David,

As someone following both the RATS WG and the SEAT WG discussions, I can
appreciate your concern about preserving the security guarantees of
draft-fossati-seat-expat. From a RATS perspective, I also share concerns
regarding RA integrations with secure channel protocols more generally. I
share your overall sentiment that care must be maintained, but I am
uncertain that an Informational-track document like
draft-ietf-rats-multi-verifier necessarily implies a new inherent risk that
you (or anyone else relying on protocols such as expat) may now be forced
to uniquely manage.

In many deployments, a monolithic Verifier already incorporates complex
internal components that the Relying Party must trust implicitly.
Therefore, compared to a single opaque Verifier, a multi=E2=80=91Verifier
architecture does not inherently increase the Relying Party=E2=80=99s trust
surface, even if complexity on the RP side may increase. By making these
components explicit under a multi=E2=80=91Verifier design, the approach (as=
 far as
I understand it) enables a Relying Party to examine, limit, and
cryptographically verify individual components with greater transparency
against the mandatory trust dependency set than was previously specified.

That said, I understand that active research on the security of
multi-verifiers is ongoing, and I'm sure the WG would be very interested in
learning about any concrete failure modes where the multi=E2=80=91Verifier =
topology
itself breaks any specific guarantees you as an I-D author depend on. A
specific example would be incredibly helpful to ensure the threat model is
fully understood.

Cheers,

Nathanael

On Thu, 7 May 2026 at 17:06, David Condrey <david=3D
40writerslogic.com@dmarc.ietf.org> wrote:

> Hi Usama, Yogesh, Jun, Houda, Henk, and the RATS WG,
>
> I am replying to voice my strong support for Usama's request to include
> the security and privacy considerations from draft-sardar-rats-sec-cons-0=
3
> (Sections 8.1.1 and 8.1.2) into the multi-verifier draft.
>
> From the perspective of other active work in this space, preserving the
> security and privacy guarantees of TLS Exported Authenticators (expat) is
> critical. As the author of drafts utilizing the Proof of Process (PoP)
> framework and related cryptographic proofs (such as
> draft-condrey-cfrg-posme and draft-condrey-rats-pop), my proposed
> architectures fundamentally rely on those expat guarantees remaining inta=
ct.
>
> If the multi-verifier architecture breaks the expat guarantees, it create=
s
> a cascading issue that undermines the threat models of downstream drafts
> that depend on them.
>
> David Condrey
>
> On Apr 29, 2026, at 4:08=E2=80=AFPM, Muhammad Usama Sardar <
> muhammad_usama.sardar@tu-dresden.de> wrote:
>
> Hi Yogesh, Jun, Houda, and Henk,
>
> We are doing research on the security and privacy of multi-verifiers, and
> we will share any solution that we will have from our analysis.
>
> For now, we have revised the proposal for security considerations
> statement [0] based on the adoption call discussion that we would like to
> be added in the draft until you or we find some reasonable solution.
>
> Privacy statement is unchanged [1] and we would like that to be added in
> the draft as well.
>
> Thank you.
>
> Best regards,
>
> -Usama
>
> [0]
> https://www.ietf.org/archive/id/draft-sardar-rats-sec-cons-03.html#sectio=
n-8.1.1-3
>
> [1]
> https://www.ietf.org/archive/id/draft-sardar-rats-sec-cons-03.html#sectio=
n-8.1.2-3
>
>
>
>
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-sardar-rats-sec-cons-03.txt
> Date: Wed, 29 Apr 2026 15:44:15 -0700
> From: internet-drafts@ietf.org
> To: Muhammad Sardar <muhammad_usama.sardar@tu-dresden.de>
> <muhammad_usama.sardar@tu-dresden.de>, Muhammad Usama Sardar
> <muhammad_usama.sardar@tu-dresden.de>
> <muhammad_usama.sardar@tu-dresden.de>
>
> A new version of Internet-Draft draft-sardar-rats-sec-cons-03.txt has bee=
n
> successfully submitted by Muhammad Usama Sardar and posted to the
> IETF repository.
>
> Name: draft-sardar-rats-sec-cons
> Revision: 03
> Title: Guidelines for Security Considerations of RATS
> Date: 2026-04-29
> Group: Individual Submission
> Pages: 14
> URL: https://www.ietf.org/archive/id/draft-sardar-rats-sec-cons-03.txt
> Status: https://datatracker.ietf.org/doc/draft-sardar-rats-sec-cons/
> HTML: https://www.ietf.org/archive/id/draft-sardar-rats-sec-cons-03.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-sardar-rats-sec-con=
s
> Diff:
> https://author-tools.ietf.org/iddiff?url2=3Ddraft-sardar-rats-sec-cons-03
>
> Abstract:
>
> This document aims to provide guidelines and best practices for
> writing security considerations for technical specifications for RATS
> targeting the needs of implementers, researchers, and protocol
> designers. This is a work-in-progress, and the current version
> mainly presents an outline of the topics that future versions will
> cover in more detail.
>
> * Corrections in published RATS RFCs
>
> * Security concerns in two RATS drafts
>
> * General security guidelines, baseline, or template for RATS
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> RATS mailing list -- rats@ietf.org
> To unsubscribe send an email to rats-leave@ietf.org
>
>
> _______________________________________________
> RATS mailing list -- rats@ietf.org
> To unsubscribe send an email to rats-leave@ietf.org
>

--000000000000ec4dee065145ee2e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi David,<br><br>As someone following both the RATS WG and=
 the SEAT WG discussions, I can appreciate your concern about preserving th=
e security guarantees of draft-fossati-seat-expat. From a RATS perspective,=
 I also share concerns regarding RA integrations with secure channel protoc=
ols more generally. I share your overall sentiment that care must be mainta=
ined, but I am uncertain that an Informational-track document like draft-ie=
tf-rats-multi-verifier necessarily implies a new inherent risk that you (or=
 anyone else relying on protocols such as expat) may now be forced to uniqu=
ely manage.<br><br>In many deployments, a monolithic Verifier already incor=
porates complex internal components that the Relying Party must trust impli=
citly. Therefore, compared to a single opaque Verifier, a multi=E2=80=91Ver=
ifier architecture does not inherently increase the Relying Party=E2=80=99s=
 trust surface, even if complexity on the RP side may increase. By making t=
hese components explicit under a multi=E2=80=91Verifier design, the approac=
h (as far as I understand it) enables a Relying Party to examine, limit, an=
d cryptographically verify individual components with greater transparency =
against the mandatory trust dependency set than=C2=A0was previously specifi=
ed.<br><br>That said, I understand that active research on the security of =
multi-verifiers is ongoing, and I&#39;m sure the WG would be very intereste=
d in learning about any concrete failure modes where the multi=E2=80=91Veri=
fier topology itself breaks any specific guarantees you as an I-D author de=
pend on. A specific example would be incredibly helpful to ensure the threa=
t model is fully understood.<br><br>Cheers,<br><br>Nathanael</div><br><div =
class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail=
_attr">On Thu, 7 May 2026 at 17:06, David Condrey &lt;david=3D<a href=3D"ma=
ilto:40writerslogic.com@dmarc.ietf.org">40writerslogic.com@dmarc.ietf.org</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv><p>Hi Usama, Yogesh, Jun, Houda, Henk, and the RATS WG,</p><p>I am reply=
ing to voice my strong support for Usama&#39;s request to include the secur=
ity and privacy considerations from draft-sardar-rats-sec-cons-03 (Sections=
 8.1.1 and 8.1.2) into the multi-verifier draft.</p><p>From the perspective=
 of other active work in this space, preserving the security and privacy gu=
arantees of TLS Exported Authenticators (expat) is critical. As the author =
of drafts utilizing the Proof of Process (PoP) framework and related crypto=
graphic proofs (such as draft-condrey-cfrg-posme and draft-condrey-rats-pop=
), my proposed architectures fundamentally rely on those expat guarantees r=
emaining intact.</p><p>If the multi-verifier architecture breaks the expat =
guarantees, it creates a cascading issue that undermines the threat models =
of downstream drafts that depend on them.</p><p>David Condrey</p><div><br><=
blockquote type=3D"cite"><div>On Apr 29, 2026, at 4:08=E2=80=AFPM, Muhammad=
 Usama Sardar &lt;<a href=3D"mailto:muhammad_usama.sardar@tu-dresden.de" ta=
rget=3D"_blank">muhammad_usama.sardar@tu-dresden.de</a>&gt; wrote:</div><br=
><div>

 =20

   =20
 =20
  <div><p>Hi Yogesh, Jun, Houda, and Henk,</p><p>We are doing research on t=
he security and privacy of
      multi-verifiers, and we will share any solution that we will have
      from our analysis.<br>
    </p><p>For now, we have revised the proposal for security consideration=
s
      statement=C2=A0[0] based on the adoption call discussion that we woul=
d
      like to be added in the draft until you or we find some reasonable
      solution.</p><p>Privacy statement is unchanged [1] and we would like =
that to be
      added in the draft as well.<br>
    </p><p>Thank you.</p><p>Best regards,</p><p>-Usama<br>
    </p><p>[0]
<a href=3D"https://www.ietf.org/archive/id/draft-sardar-rats-sec-cons-03.ht=
ml#section-8.1.1-3" target=3D"_blank">https://www.ietf.org/archive/id/draft=
-sardar-rats-sec-cons-03.html#section-8.1.1-3</a></p><p>[1]
<a href=3D"https://www.ietf.org/archive/id/draft-sardar-rats-sec-cons-03.ht=
ml#section-8.1.2-3" target=3D"_blank">https://www.ietf.org/archive/id/draft=
-sardar-rats-sec-cons-03.html#section-8.1.2-3</a><br>
    </p><p><br>
    </p>
    <div><br>
      <br>
      -------- Forwarded Message --------
      <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0">
        <tbody>
          <tr>
            <th valign=3D"BASELINE" nowrap align=3D"RIGHT">Subject:
            </th>
            <td>New Version Notification for
              draft-sardar-rats-sec-cons-03.txt</td>
          </tr>
          <tr>
            <th valign=3D"BASELINE" nowrap align=3D"RIGHT">Date: </th>
            <td>Wed, 29 Apr 2026 15:44:15 -0700</td>
          </tr>
          <tr>
            <th valign=3D"BASELINE" nowrap align=3D"RIGHT">From: </th>
            <td><a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blan=
k">internet-drafts@ietf.org</a></td>
          </tr>
          <tr>
            <th valign=3D"BASELINE" nowrap align=3D"RIGHT">To: </th>
            <td>Muhammad Sardar
              <a href=3D"mailto:muhammad_usama.sardar@tu-dresden.de" target=
=3D"_blank">&lt;muhammad_usama.sardar@tu-dresden.de&gt;</a>, Muhammad
              Usama Sardar <a href=3D"mailto:muhammad_usama.sardar@tu-dresd=
en.de" target=3D"_blank">&lt;muhammad_usama.sardar@tu-dresden.de&gt;</a></t=
d>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      A new version of Internet-Draft draft-sardar-rats-sec-cons-03.txt
      has been<br>
      successfully submitted by Muhammad Usama Sardar and posted to the<br>
      IETF repository.<br>
      <br>
      Name: draft-sardar-rats-sec-cons<br>
      Revision: 03<br>
      Title: Guidelines for Security Considerations of RATS<br>
      Date: 2026-04-29<br>
      Group: Individual Submission<br>
      Pages: 14<br>
      URL:
      <a href=3D"https://www.ietf.org/archive/id/draft-sardar-rats-sec-cons=
-03.txt" target=3D"_blank">https://www.ietf.org/archive/id/draft-sardar-rat=
s-sec-cons-03.txt</a><br>
      Status:
      <a href=3D"https://datatracker.ietf.org/doc/draft-sardar-rats-sec-con=
s/" target=3D"_blank">https://datatracker.ietf.org/doc/draft-sardar-rats-se=
c-cons/</a><br>
      HTML:
      <a href=3D"https://www.ietf.org/archive/id/draft-sardar-rats-sec-cons=
-03.html" target=3D"_blank">https://www.ietf.org/archive/id/draft-sardar-ra=
ts-sec-cons-03.html</a><br>
      HTMLized:
      <a href=3D"https://datatracker.ietf.org/doc/html/draft-sardar-rats-se=
c-cons" target=3D"_blank">https://datatracker.ietf.org/doc/html/draft-sarda=
r-rats-sec-cons</a><br>
      Diff:
      <a href=3D"https://author-tools.ietf.org/iddiff?url2=3Ddraft-sardar-r=
ats-sec-cons-03" target=3D"_blank">https://author-tools.ietf.org/iddiff?url=
2=3Ddraft-sardar-rats-sec-cons-03</a><br>
      <br>
      Abstract:<br>
      <br>
      This document aims to provide guidelines and best practices for<br>
      writing security considerations for technical specifications for
      RATS<br>
      targeting the needs of implementers, researchers, and protocol<br>
      designers. This is a work-in-progress, and the current version<br>
      mainly presents an outline of the topics that future versions will<br=
>
      cover in more detail.<br>
      <br>
      * Corrections in published RATS RFCs<br>
      <br>
      * Security concerns in two RATS drafts<br>
      <br>
      * General security guidelines, baseline, or template for RATS<br>
      <br>
      <br>
      <br>
      The IETF Secretariat<br>
      <br>
      <br>
    </div>
  </div>

_______________________________________________<br>RATS mailing list -- <a =
href=3D"mailto:rats@ietf.org" target=3D"_blank">rats@ietf.org</a><br>To uns=
ubscribe send an email to <a href=3D"mailto:rats-leave@ietf.org" target=3D"=
_blank">rats-leave@ietf.org</a><br></div></blockquote></div><br></div>_____=
__________________________________________<br>
RATS mailing list -- <a href=3D"mailto:rats@ietf.org" target=3D"_blank">rat=
s@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:rats-leave@ietf.org" targ=
et=3D"_blank">rats-leave@ietf.org</a><br>
</blockquote></div>

--000000000000ec4dee065145ee2e--