IETF Logo Mail Archive

[Lake] Re: Comments for remote attestation over EDHOC

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 27 May 2024 14:33 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 B18DEC18DB90 for <lake@ietfa.amsl.com>; Mon, 27 May 2024 07:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=sandelman.ca
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 O17SVNEr8aP2 for <lake@ietfa.amsl.com>; Mon, 27 May 2024 07:32:56 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97B1BC1782B5 for <lake@ietf.org>; Mon, 27 May 2024 07:32:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E20623898D; Mon, 27 May 2024 10:32:54 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wjyiQQlRgAbZ; Mon, 27 May 2024 10:32:53 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E358C3898C; Mon, 27 May 2024 10:32:52 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1716820372; bh=3OvZwCqU5zfkk3YVFw37Wj3R4HcE+/vh07HsxbZgIXg=; h=From:To:Subject:In-Reply-To:References:Date:From; b=wuXn2V7UdBrlmXB86uqw7Wz0dxuRNlRJf7r0iAvK+QOCrGCSiAaBSAw8uocc3D+XQ OTNQj7S94zCnSAQX5oGLochaULadA8KxmJxNc7emvZuM2NJ6hCZvxpLBs3MZVM39+K 8wkgTRALwFNJ1obI0Y2KU+Y1I3v5C88L//0GTXLwLrqTml87XOcOhXYxKZaM4tIGLS TTo5EMwIbT585L89SjAah+eZ9JE5oAIQnDsXdJOqxgwd5u9aUlhyVvOoy3yuVW19c7 BMUbExBzpgnLW1lYQBfzcqnMUIjrZ6be27UmbvVrS7YIUKOjACwmRZUCF0l9jeB46W 4IGj1pHvqCglA==
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DECE0167; Mon, 27 May 2024 10:32:52 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>, lake@ietf.org
In-Reply-To: <88819c94-9cbc-44c1-ab0f-9fe6e9ed1a8e@tu-dresden.de>
References: <ae2173a6-cc15-44c9-aa14-f5e7ab625201@tu-dresden.de> <14134.1716600042@obiwan.sandelman.ca> <88819c94-9cbc-44c1-ab0f-9fe6e9ed1a8e@tu-dresden.de>
X-Mailer: MH-E 8.6+git; nmh 1.8+dev; GNU Emacs 28.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0;<'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Message-ID: <14114.1716820372@obiwan.sandelman.ca>
Message-ID-Hash: F45ITN7AQAT2VFOYODPH5FCEEUEEKBS5
X-Message-ID-Hash: F45ITN7AQAT2VFOYODPH5FCEEUEEKBS5
X-MailFrom: mcr+ietf@sandelman.ca
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/Ec7C7EuaLaYZxxtdhqP3NiChn4A>
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>
Date: Tue, 28 May 2024 08:23:23 -0000
X-Original-Date: Mon, 27 May 2024 10:32:52 -0400

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> wrote:
    >> > 1. /Clarify the EDHOC and RA combinations/: EDHOC has two participants
    >> > (Initiator and Responder) and RATS architecture (RFC9334) defines three roles
    >> > (Relying Party, Verifier and Attester). I think it is important to clarify
    >> > which combinations are not possible or otherwise possible but not covered by
    >> > the specs.
    >>
    >> I don't see the conflict.

    > I never mentioned any "conflict", so I am not sure what you conceived as the
    > "conflict." In my mind, it was about:

Any and all combinations are *possible*

    >> I don't expect two constrained devices to be able to perform remote
    >> attestation on each other.

    > The editor of the draft does! I also heard someone else mentioning this
    > during the Hackathon.

Well, I don't see how a constrained device is going to be able to act as a
Verifier.   As a RP?  Maybe.

    >> But, even if they were CRAYs with the padded
    >> seats, it still makes no-sense.
    >> In the context of lake-authz, the Attester is the new device (U), the Verifier is
    >> W (or it's designate), and the Relying Party is V.

    > The draft under discussion never makes a reference to lake-authz.

It should.

    >> 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.


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

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