[Rats] Re: Call for adoption: draft-deshpande-rats-multi-verifier-04 (Ends 2026-04-24)

Manu Fontaine <Manu@hushmesh.com> Thu, 23 April 2026 13:20 UTC

Return-Path: <manu@hushmesh.com>
X-Original-To: rats@mail2.ietf.org
Delivered-To: rats@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 08A52E1B16D6 for <rats@mail2.ietf.org>; Thu, 23 Apr 2026 06:20:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776950440; bh=EJSTbl1UYOLlrs547ns0CVlHRsE/FU3Jv3pP2cTwLf4=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=dUIxb/gLTowrdn0dHev17URnsN49gfL+MEci3JhbvlCC3u4mI1iusCwKdGAjEjOj2 sWtLCaZVlt7OXaNWKA+2mStyPsHnz0c0Q5PhKAHxrpOIjsxOfRXVlnVKejRDu9G1ag T3F1ComaN0qBOdxJOuTBmqsGi3akUXBPUChJYO/M=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=hushmesh-com.20251104.gappssmtp.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 dJxPfmd7E4Lz for <rats@mail2.ietf.org>; Thu, 23 Apr 2026 06:20:35 -0700 (PDT)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 26063E1B1578 for <rats@ietf.org>; Thu, 23 Apr 2026 06:19:47 -0700 (PDT)
Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-b886fc047d5so1185856066b.3 for <rats@ietf.org>; Thu, 23 Apr 2026 06:19:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1776950386; cv=none; d=google.com; s=arc-20240605; b=hx11TrexKzjvKFEyL6MZx7apc5LvtIr4VT8HioGCBdZ3RSH4zYq51EKA54VHhDGo60 eSCulwn0mWjAWScmgX0MlXsogt4heCCiuRXoo+QTviaJxg4de2k/+qaAm/F7vAZxGUk0 tgnEPh8X/Tg/00nBwLRFffjWTZ1ElervHCg2WHB9V1zS7OceEUfdBGiPf+BKdhhnIm2J RAbdS5d2Wn5v2Da5eGotqG5u7vWtUxKSJy61qhdw9YczJ/3QpPgUZ1AhBqv1za0V9elY cgwhOD7OhRbmP1I8ytn8MVbT34oI/3E1xEVjiFpzjpJOL3tsA2mzgwm0BWrV6eiRuOAP KmWw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=pEs8Y/GOj3t2QIQNJkVe6KvsL3uM3cVe7jfJaxDQbU4=; fh=aEtSZqYXif6Kt3KCzcl5fezdOkC4d+ZvAFSFS+kCPVw=; b=ggRMvnutdqHVRzgGzFv5tL8+UrAIzSfRjgFaneO6ISCyAZbeD0356Ycj3LKhzFmnDh 5D8UwwbNXjF53DA/zPEM7nu+b2zU2iYJac958s6/4d5D3IH6QmaYnLw8WtLP10EQ6257 VFB4Cf7O8JvyLnbxkmSgJOgakVT3RYb1A73GQdY0S/imbI1xYYD0grHNST0fGaWTimFb tiitfZgbhw+T9g52xk1fneB5rIjLzlK8a7PzvYhJwOpGCTemeXsNRK5B0tQRxMbkXqrV plG/g4UY2M5RZPBb0C3Uwhy/o77i40tLJsIakAy2rXbFIgcW+Q3QlU/AMzuu/1FX64Z+ Qfng==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hushmesh-com.20251104.gappssmtp.com; s=20251104; t=1776950386; x=1777555186; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pEs8Y/GOj3t2QIQNJkVe6KvsL3uM3cVe7jfJaxDQbU4=; b=FQcXICETWp8IlsrLsnKNDRfS7BWTiLJd049FSjkqxR//6JxoF/c4+ROdPYlLam/sUw 57qnADiJYLeBKKwyU8IYZEukyKT/VbUCC7HpdMaehnNbyPFiBevGezJQn9DdKp7lLlv+ HQvJDyLKIWLSqz6M8lkElAxGpMfwHcm4aS/4jN0AWPPRfFxE2TeX8buZRz/9r7w6fi3a GrNNXxJJzSKK/P503HrQQnZqk7b2kYBU9NliipAuqr+yC7PCCphX6pnYKWqq7IJ4O9nC GD92ZxTyWQE7aAN5MqlLJsWo6rwlAC5PqYfhGfzuoiikDZdv6h1Qk1LMX+DT6Bqn615S bSJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776950386; x=1777555186; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pEs8Y/GOj3t2QIQNJkVe6KvsL3uM3cVe7jfJaxDQbU4=; b=RVWjPHbnYSaXVlAyj8s+RYy1PupEC7w2Q+Mw91QDFXj2vGibtAAplnkYbg2tWsgZPu ogAfWcU0M3mJmMqVy72Db2n88grL66bfapoSqw7PKXRirOydC/FZT29VFasfeH+mRRPj cIgD9sYP0R1P2Lc3Rb0MpsnOX4RAwOBvNCStEJjKje0UBQYM1y6Ktuex3w7bkqVT/XiA 4mGXmQ3l2kc5vLouF7J2UswIT+tW7fr/JGrYeoNxnxb8x8DgE+Ki54SoxgGVPhTE9Wo0 DEN53YMGqE1/F8xA1YnvfYSBe1zg/HVOW29gIRcR0oCbqmDkCTejTgw5CNPxuwCeckPV QhNQ==
X-Forwarded-Encrypted: i=1; AFNElJ8c42N0jbSiajo6x+rfw34asBwWzQXsXRptYvFlzXuF90pRkXsHKlEejTd8iaxukY/9DkfK@ietf.org
X-Gm-Message-State: AOJu0YygfZB8XEN9D680Z4eAb+bnDjS8B0RymYMGNMFc8xh2AowQFg1F MxcWfFtRxNZeW75R1lNour/vsulsP/zbWeRCy0tsfsyk+xCHCRtlihS9mCCu2x689oYnVYE0hhC q990DvzUqBFBpe4/gjtkwe2t/bE1rVKLYXdmpcMzLGQ==
X-Gm-Gg: AeBDieswoIQR7fBzTQIqu/M27UwW2FXSK1yBpDtXYwD1L4kPw1bCs1VyC2pHj0yNGrT ggxQMx+jHRc8AXsGw7z1apsQhHfIj6GMWNZ1/xoDYcwNKa3X1yfj2r5ErzPY2UlHX1Ex258/hrS xdV8twX2njyWMolaPgB64+qnh2koAtsc/9buZtpIrprmIucF5thjaWyooCIW5bHEv4ZadrghdV7 PQVWnE2BGgL+YHh84v69L8FpzlgbfTKSArlqvxzPLSa2gQmhPQEzQF6JAcaiQ5eXdSYNZJ+xx5U do8EY7+rzIKHceTxvMlGZiTqEsoKa0NAQss7Tn8nCUnCf/Y5yoRxtj4cNZpy6A==
X-Received: by 2002:a17:907:961b:b0:b9d:33b5:6ba1 with SMTP id a640c23a62f3a-ba41c1b6fbdmr1384343466b.15.1776950385805; Thu, 23 Apr 2026 06:19:45 -0700 (PDT)
MIME-Version: 1.0
References: <0f2dd332-cda4-4950-83b2-25cbf276b548@tu-dresden.de> <F78785FF-B962-44E9-871E-053B9DD1DA96@gmail.com>
In-Reply-To: <F78785FF-B962-44E9-871E-053B9DD1DA96@gmail.com>
From: Manu Fontaine <Manu@hushmesh.com>
Date: Thu, 23 Apr 2026 09:19:33 -0400
X-Gm-Features: AQROBzChYM3H74-J7hGfhQwx-SAradRy3H8TuVhfLs-u-XbDl4N7W7X1pO0HJls
Message-ID: <CAHu=PL2qys3-_b_T8vufDgtsGv4g7U4XmzHYZOt0OkU=qECcWg@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000879bb30650208051"
Message-ID-Hash: XOXWLAEPLQWSBMF6UFSENBMGSHKG5MAN
X-Message-ID-Hash: XOXWLAEPLQWSBMF6UFSENBMGSHKG5MAN
X-MailFrom: manu@hushmesh.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rats.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: rats@ietf.org, rats-chairs@ietf.org, draft-deshpande-rats-multi-verifier@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Rats] Re: Call for adoption: draft-deshpande-rats-multi-verifier-04 (Ends 2026-04-24)
List-Id: Remote ATtestation procedureS <rats.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/DhetjTmpQFs84n_F5RHk-nb48UA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Owner: <mailto:rats-owner@ietf.org>
List-Post: <mailto:rats@ietf.org>
List-Subscribe: <mailto:rats-join@ietf.org>
List-Unsubscribe: <mailto:rats-leave@ietf.org>

I'm not trying to block anything (because I do not have enough bandwidth to
participate actively) but Usama's point is more fundamental than "security
and privacy considerations".

The quality of a relying party trust decision (which includes security and
privacy considerations) collapses rapidly with each additional independent
verifier. Each independent verifier introduces its own trust dependencies.
Just one compromised verifier can compromise the final trust decision.
Trust is not additive; it's a chain only as strong as its weakest link.

The draft correctly states that multiple verifiers are necessary, and must
collaborate, but it doesn't contemplate that the collaboration should
itself be cryptographically verifiable. This is a recursive architecture
challenge, where component verifiers must themselves be verified by a
shared verifier to minimize the degradation of the relying party's trust
decision.

Relying on institutional trust for composition use cases (essentially all
of them from the relying party's perspective) inherently undermines the CC
value proposition.

M


On Thu, Apr 23, 2026 at 6:57 AM Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com> wrote:

> I hadn’t seen this message as I was on vacation.
>
> Usama, security & privacy considerations can be developed in the WG and
> are not blocking.
>
> One person cannot block consensus either or it would lock up work between
> competitors regularly.
>
> The draft will have the consensus marker turned on when the chairs deem it
> appropriate after WGLC. Please be kind to other participants and leave the
> chairs to do their job on consensus decisions.
>
> Best regards,
> Kathleen
>
> Sent from my mobile device
>
> On Apr 22, 2026, at 3:19 PM, Muhammad Usama Sardar <
> muhammad_usama.sardar@tu-dresden.de> wrote:
>
> 
>
> Hi all,
>
> I didn't notice that this is already ongoing.
>
>
> # *Technical concerns*
> On 17.04.26 16:31, Ned Smith via Datatracker wrote:
>
> Please reply to this message and indicate whether or not you support adoption
> of this Internet-Draft by the rats WG. Comments to explain your preference
> are greatly appreciated.
>
> I *strongly oppose* adoption of this draft -04 in its current form
> because of substantial technical concerns already mentioned several times
> on the list, in the meetings and in my draft [0]. Some recent discussions
> are [1,2] to which no technical response has been provided. IMHO, this
> draft in its current form is doing disservice to the community by not
> properly highlight the security and privacy risks, and by implicitly
> promoting the blind trust in vendors.
>
> Given that neither the draft has addressed these substantial technical
> concerns nor any technical argument has been provided on list, I believe
> the document would benefit from further discussion and revision before
> being considered for adoption. Please let me know if I have missed
> something.
>
>
> # *Procedural concerns*
>
> ## *Repeated misuse of "Consensus"*
>
> I watched the recording of meeting 125. I am deeply concerned about the
> repeated misuse of the word "consensus" in authors' recent presentations of
> this draft, because this has happened repeatedly.
>
> In IETF 123, authors said verbally that "consensus has been reached in a
> side meeting" which is absolutely wrong, because WG business cannot be done
> in side meetings.
>
> Now in IETF 125, authors are saying and even writing in the slides [3]
>
> "consensus reached in IETF 124"
>
> which is not correct because I voted "no" in IETF 124 and even mentioned
> on mic that my concerns should be addressed before adoption. I believe
> claiming "consensus" while my substantial technical concerns remain
> unaddressed undermines the IETF process. I request technical answers to my
> technical concerns before adoption.
>
> ## *Duration of adoption call*
>
> IIUC the chairs said two times adoption call will be for at least 2 weeks
> [4,5] and then Henk asking it again on mic saying "2 or 3 weeks" and chairs
> confirming it [6]. I don't know what changed it to one week, especially
> given the confusion in the other thread about adoption. I would like to
> know if I have missed something.
>
>
> Best,
>
> -Usama
>
>
> [0]
> https://www.ietf.org/archive/id/draft-sardar-rats-sec-cons-02.html#section-8.1
>
> [1]
> https://mailarchive.ietf.org/arch/msg/rats/bL70CcpPS8UwuNbSKygDlMIONdw/
>
> [2]
> https://mailarchive.ietf.org/arch/msg/rats/dsmW2IODYw2886qju1RwQwdUoyA/
>
> [3]
> https://datatracker.ietf.org/meeting/125/materials/slides-125-rats-remote-attestation-with-multiple-verifiers-00
>
> [4] https://youtu.be/uNLHwnJRSCI?t=5630
>
> [5] https://youtu.be/uNLHwnJRSCI?t=5652
>
> [6] https://youtu.be/uNLHwnJRSCI?t=5680
>
> _______________________________________________
> RATS mailing list -- rats@ietf.org
> To unsubscribe send an email to rats-leave@ietf.org
>