IETF Logo Mail Archive

[Lake] Re: Comments for remote attestation over EDHOC

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Tue, 28 May 2024 07:38 UTC

Return-Path: <muhammad_usama.sardar@tu-dresden.de>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19812C15109C for <lake@ietfa.amsl.com>; Tue, 28 May 2024 00:38:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 okFSccEX3poo for <lake@ietfa.amsl.com>; Tue, 28 May 2024 00:38:47 -0700 (PDT)
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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDAB6C14F5E7 for <lake@ietf.org>; Tue, 28 May 2024 00:38:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-dresden.de; s=dkim2022; h=In-Reply-To:From:References:To:Subject: MIME-Version:Date:Message-ID:Content-Type:Sender:Reply-To:Cc: 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=+JYBLp0p3Li2AHv6ypUkfrrZFF6cBsxjGSQRP2kWD3c=; b=HrwEbK/7wWoRg8uuI1JnB6HSRq CrD5gaA3DrKCNI7sbW+WpHZVOxP8fADDJ1/9Vl7FZwhwChplhsglmqwTKsAlAYzY9Ph08t8Rlv81t oVAyS08oDpvh3RTag3bwbHH+LA6YD0XwVpHuSNbm6Vkzdh0rX8kye3zc+RSAz3eRutYphLvehe+G0 Sg8ewceFhapdEas0jpqvDsyC9ZfxHzCAHprAqadTj5jisEiHznzMkWG2h7f6qBIzjpTbNc6WWz5lM OcsvKG9n6NjnmUtXNSqZfTlrW07h0AGWtD6g/EYKMF8+Jiz/YRaZyleNS4+HSpwJV3JX+KPUqWx84 IhctHneA==;
Received: from [172.26.35.114] (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 1sBrPx-00FMeR-HU; Tue, 28 May 2024 09:38:45 +0200
Received: from [10.70.3.98] (194.95.143.137) by MSX-T314.msx.ad.zih.tu-dresden.de (172.26.35.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Tue, 28 May 2024 09:38:39 +0200
Content-Type: multipart/alternative; boundary="------------ELZxl0eEyRXJpF6jUx5Ejhdr"
Message-ID: <759c00b7-aa7b-44f6-845d-d04e2e899151@tu-dresden.de>
Date: Tue, 28 May 2024 09:38:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Michael Richardson <mcr+ietf@sandelman.ca>, lake@ietf.org
References: <ae2173a6-cc15-44c9-aa14-f5e7ab625201@tu-dresden.de> <14134.1716600042@obiwan.sandelman.ca> <88819c94-9cbc-44c1-ab0f-9fe6e9ed1a8e@tu-dresden.de> <14114.1716820372@obiwan.sandelman.ca>
Content-Language: en-US
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <14114.1716820372@obiwan.sandelman.ca>
X-ClientProxiedBy: msx-l319.msx.ad.zih.tu-dresden.de (172.26.34.119) To MSX-T314.msx.ad.zih.tu-dresden.de (172.26.35.114)
X-TUD-Virus-Scanned: mailout4.zih.tu-dresden.de
Message-ID-Hash: NO6IIQZN6IZURMJDQL3IH4TQW6Y3TZDJ
X-Message-ID-Hash: NO6IIQZN6IZURMJDQL3IH4TQW6Y3TZDJ
X-MailFrom: muhammad_usama.sardar@tu-dresden.de
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
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Lake] Re: Comments for remote attestation over EDHOC
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/3Jwt9yTkTtwNsU4ik8xQ8An3j-s>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Owner: <mailto:lake-owner@ietf.org>
List-Post: <mailto:lake@ietf.org>
List-Subscribe: <mailto:lake-join@ietf.org>
List-Unsubscribe: <mailto:lake-leave@ietf.org>

On 27.05.24 16:32, Michael Richardson wrote:
> Any and all combinations are *possible*
>
>
> Well, I don't see how a constrained device is going to be able to act as a
> Verifier.
>
Now I see a clear contradiction in the two statements above.
>      >> I have a half-written document on putting EAT into the full BRSKI protocol.
>      >> A reason that I stopped is that I realized that doing security posture
>      >> evaluation at onboarding time (only) wasn't enough.  It has to be done
>      >> regularly.  So having a protocol used at onboarding time and another one
>      >> during normal operation meant that the onboarding one would have bugs that
>      >> never get fixed, since the code only runs once.
>
>      > It seems very interesting. What kind of bugs? Can you give a few examples of
>      > the "bugs that never get fixed"? Which "code" exactly? Are you advocating
>      > that having attestation during secure channel establishment for IoT
>      > onboarding is useless?
>
> Code that runs only once in a device's lifetime likely has bugs that nobody
> notices and never get fixed.
>
I am still struggling to find out what exactly is your opinion, and what 
is the scientific argument behind that. Are you advocating that 
attestation is useless during secure channel establishment for IoT 
onboarding?

Regards,

Usama

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