IETF Logo Mail Archive

[Rats] Re: Security considerations of remote attestation (RFC9334)

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Fri, 24 January 2025 15:14 UTC

Return-Path: <muhammad_usama.sardar@tu-dresden.de>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EB5C1CAF42 for <rats@ietfa.amsl.com>; Fri, 24 Jan 2025 07:14:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.403
X-Spam-Level:
X-Spam-Status: No, score=-4.403 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tu-dresden.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZbI-j7rkwOc for <rats@ietfa.amsl.com>; Fri, 24 Jan 2025 07:13:58 -0800 (PST)
Received: from mailout4.zih.tu-dresden.de (mailout4.zih.tu-dresden.de [141.30.67.75]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0376CC1CAE72 for <rats@ietf.org>; Fri, 24 Jan 2025 07:13:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-dresden.de; s=dkim2022; h=Content-Type:In-Reply-To:From:References:CC:To :Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=s8NobuvwJZU2qIeLgVG1hZ4R2c2ueCGB4xAcZt9+AWM=; b=Z6PpFScGg0VGlJL5VxnVuZdrpr 4zYbucZpqpQMWbL3idKgFTHBTjg3ZCFcdK9XdsP+e4OwTjOD0tuGJcgc32+03jBTPpjeeYSdggOEz 9aLNBAoPprK2/NsnpHEkZebnF1aBMwZ/KEDOEnZGSEgdMJCggig8/INeQKZpi/E8CmxaYDHI00DAO /6EGyEaKwtRFJQq9/gGem7fguZMpk9hlE3jDa+7bOxNkWYTTsIBMjhYvzw1CGEREs7l/kxlPqf7rD J/TBkFMECb5BcRNpqyfvuZYXDhc56RkxGz8AXrpBlvUAZcLm2XBPapmeZNmQ5ZNxRWiZTZJ4tvK73 NMOtQVww==;
Received: from [172.26.35.139] (helo=msx.tu-dresden.de) by mailout4.zih.tu-dresden.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <muhammad_usama.sardar@tu-dresden.de>) id 1tbLNN-0061bw-Bq; Fri, 24 Jan 2025 16:13:41 +0100
Received: from [192.168.1.2] (77.191.10.197) by msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14; Fri, 24 Jan 2025 16:13:36 +0100
Message-ID: <7f0fdc10-ef5b-4a98-829f-3d5833762086@tu-dresden.de>
Date: Fri, 24 Jan 2025 16:13:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Henk Birkholz <henk.birkholz@ietf.contact>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
References: <4ffdd034-05ec-4565-9cad-b40ff82f83fc@tu-dresden.de> <2E15F514-29BF-4763-A844-5E38CDEF5791@island-resort.com> <17359f9b-914e-4d3d-8923-92bdf2cc887e@tu-dresden.de> <983AE2D0-D1CF-43F6-8888-F6D0487B4B8E@island-resort.com> <bf973538-b390-4c60-8c99-7a93f00c3833@tu-dresden.de> <F78D9011-E0A8-43E6-A1BA-DDA44BF24348@island-resort.com> <57ff8532-ffa7-4dfc-8f51-2bb8764e4a25@gmail.com> <0bf9fa63-3d3e-47fc-b757-d7f8c0d3fa9c@tu-dresden.de> <8f765ee8-08e4-4fd6-9362-aee70e0b09fc@gmail.com> <CO1PR11MB5169C33046305CE096FEA36DE51C2@CO1PR11MB5169.namprd11.prod.outlook.com> <003f6611-efd4-4b41-8bd8-a1e8d89dab8a@tu-dresden.de> <2753ea96e5c842e2832b68e762638760@huawei.com> <2ce75ea8-791b-4d42-be64-326309b70fbe@tu-dresden.de> <CO1PR11MB5169293FDD81C96F542A4D91E5E32@CO1PR11MB5169.namprd11.prod.outlook.com> <4fe69a8b-ff45-45c3-88f1-59bf22c4d185@tu-dresden.de> <CAHbuEH6+A9z2P2mK1mUJUMCkC5VbawU5B09k6s1pm0YwXJygEQ@mail.gmail.com> <775705ed-44d3-8c67-198d-1b6363892793@ietf.contact>
Content-Language: en-US
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <775705ed-44d3-8c67-198d-1b6363892793@ietf.contact>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms080005000705090804080004"
X-ClientProxiedBy: MSX-L414.msx.ad.zih.tu-dresden.de (172.26.34.134) To msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139)
X-TUD-Virus-Scanned: mailout4.zih.tu-dresden.de
Message-ID-Hash: ATDGEZNRHEDGCEQJKQDLJHJRIS7OYOC2
X-Message-ID-Hash: ATDGEZNRHEDGCEQJKQDLJHJRIS7OYOC2
X-MailFrom: muhammad_usama.sardar@tu-dresden.de
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: "Smith, Ned" <ned.smith@intel.com>, "Panwei (William)" <william.panwei@huawei.com>, John Kemp <stable.pseudonym@gmail.com>, "rats@ietf.org" <rats@ietf.org>, Dave Thaler <dthaler1968@googlemail.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Rats] Re: Security considerations of remote attestation (RFC9334)
List-Id: Remote ATtestation procedureS <rats.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/5u6bdThVpHCGnD-ZVedyEs3JnXE>
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>

Hi Henk,

please see a few questions inline

> (3) In conclusion, I agree with the statement that: "every 
> authentication procedure can be augmented with a remote attestation 
> procedure". 

4 questions for this statement:

 1. What /exactly/ is your definition of /authentication/ /procedure/?
 2.  From what /exactly/ are you concluding this statement? You say "in
    conclusion" but I don't see any other supporting argument from which
    you "concluded" this.
 3. Is there really a need to augment /every/ authentication procedure
    with remote attestation procedure? If yes, state /exactly/ what it is.
 4. The problem is that the existing attested TLS protocols do not
    /augment /authentication, they /replace/ authentication with remote
    attestation. Do you think augmenting is possible with TLS without
    major changes in the protocol? For instance, CertificateVerify
    message in TLS is not extensible. You can provide
    proof-of-possession of only one key.

> I acknowledge that it sometimes is a bit tricky to squeeze certain 
> RATS Conceptual Message Flows models in exiting protocol 
> specifications (as we see with TLS and emerging aTLS). I also 
> acknowledge that the reference interaction models do not directly 
> match every protocol message flows that exists in protocols today. 
> Both mappings (RATS CM Flows 2 protocol) and (RATS Reference IMs 2 
> protocol) never have been intended to be perfect matches. It is always 
> necessary to specify the necessary parts that fill the gaps in the 
> corresponding Internet-Drafts.
>
What then is the real value of specifying RATS CM Flows and RATS 
Reference IMs and why do we need those? I am asking this because the 
only useful thing I can borrow from RATS Reference IM draft for attested 
TLS draft is that it is challenge-response model. But that is a 
well-known terminology for decades. Particularly, for TEEs, there is no 
ambiguity at all, because there is typically no trusted time.

v2.46.0 | Report a Bug | By Email | System Status