[nasr] Re: [saag] Re: NASR BOF Follow-Up

Eric Rescorla <ekr@rtfm.com> Wed, 16 April 2025 02:16 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: nasr@mail2.ietf.org
Delivered-To: nasr@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id BB5361CB5E44 for <nasr@mail2.ietf.org>; Tue, 15 Apr 2025 19:16:27 -0700 (PDT)
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=rtfm-com.20230601.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 8ja5CEEPdS-9 for <nasr@mail2.ietf.org>; Tue, 15 Apr 2025 19:16:27 -0700 (PDT)
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 284E91CB5E38 for <nasr@ietf.org>; Tue, 15 Apr 2025 19:16:27 -0700 (PDT)
Received: by mail-yb1-xb2a.google.com with SMTP id 3f1490d57ef6-e6cea43bb31so4624938276.0 for <nasr@ietf.org>; Tue, 15 Apr 2025 19:16:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1744769786; x=1745374586; 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=nc0cZtHjUXOUPI0GNk8gbWPsLBAsaSDPLu/UaDlbZDs=; b=MCx0brGHUBJedMmY5s/7u5ycDN6dqL6kHdVH8RaKGcijBdL/Y249OIU0WiqIFVdN3z n9/xMGGhLYi8UdkOzjzKFU4p9DrCElfgvvOHW1YTiwBt+5P1tnEx74e5UDc1Hm7Al0hc FWTFQO8U/496OE81jTXtdAhJaKkoE2BQt/mVtmqaFs9ShrMcG2FGYHMTv/VPN1ckJbeO RFa3K/A9gvtYb+AbRewr1zBKL4/6q7GBdl0e0iJoGAGzbrNKykrG9DPYLWXLHbX1neLa GBb0P/k83e5iyFuGdVQr1OVZoqnAP4vzmsENfXwe9d5DHyWmp5cr80s0lID5rZuZTe4Z NnRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744769786; x=1745374586; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nc0cZtHjUXOUPI0GNk8gbWPsLBAsaSDPLu/UaDlbZDs=; b=ACOiPOAAuq4PwTyJW+Ab1Q/5c/crggwv+W5QbytN4z2wyaNpParg052Sl9m/ragvBU 4s6pQLLnYMzRkWQLXGBsC96vPC1iKeVjG3MEnqvvcfxaxClLEeewrFOBdehlDpoMlGLc 8RLVipS/0e0EHAPs5mPukY8pzRBJJlGJmZBp5GhJ0tpDPO4LEvtk/VO3B9Ffcj1A1mP9 1//wybPY3U53u3oT8PHaJ1w6xtYtexdvG9A8qAtrTp6DiuR6MVjvZeaGAKlbeE9EBcic 1RGrPQfYh7Evd4MqSjWNIYnpIXZE/9iWAiMnTfkv1pnKhUn0+6fjjmYtA00HUVAWHj9i Wt/A==
X-Forwarded-Encrypted: i=1; AJvYcCXN82mp48M/RLNfwkVxHwQYVQldZJJBzh0zFT9yd/BYW6/FVs7Dy4Jhyppx+v6xWhh3VpPq@ietf.org
X-Gm-Message-State: AOJu0YwQ979zrhvjTdfEbu/J8Z7hfyd9ox/k9EJfS02rq6W8thZME1d3 4BforJEr58/8qPGOdEHnc5RroKsWWhhk+ykpmk+w2hV5fjdE+XX+4NGpc1gYxW9shFhpz5m1yCU 92xPQBlf8uKFghsfeVt9VHSLGq71PX0IBl72PLaVrvpKR1xrm
X-Gm-Gg: ASbGncs77n0AL+3oIDVGm8ZJMTPNg1vIlXTudoZkQIsgIld26sx0HzWmC9VR2Je9+Wn CD9/ROn0yTXvdBwz8mAeXv3cIxyrn1NmMa+D9zcIjFbEJ93HB2EgqByAQR4Ua+2x4kToVBD0yNQ +UkgM1Li7E7Csw2vKB8ekp1Hav
X-Google-Smtp-Source: AGHT+IFBL2WXOXvGYhpWWvO5EIzk6+CJ2M6F26R6mM1KzO7B4o922tNL4Yg5xEQ5mU+0+Td2KQf9xposoBGPCNoJQ/M=
X-Received: by 2002:a05:6902:1792:b0:e6d:ecbb:e515 with SMTP id 3f1490d57ef6-e7275f1b73bmr127302276.32.1744769786526; Tue, 15 Apr 2025 19:16:26 -0700 (PDT)
MIME-Version: 1.0
References: <ef08bf0afa924713acc629dff8156761@huawei.com> <2025040312042771743841@chinamobile.com> <CAL02cgSg53nOB8BCSNCLGC78r41P_1VzBPoj2yOJP1qbS0jqfA@mail.gmail.com> <CABcZeBPFaJMsWyNozXS+osh251631vCStkrmOk=WQig5c1_0qw@mail.gmail.com> <87c61c52-839f-f66e-a66a-b737f01ca93f@ietf.contact> <CABcZeBMOvFXkQ2OFBpz2Ri5_Oz-pHGs=2fHvBNptOdjQy9F7ww@mail.gmail.com> <11730e71-f409-bbaf-9bc1-4f88d207bcab@ietf.contact> <CABcZeBMDg9cFGtf6AMwSiq3ZnZnrvwoAc7TjD0Ftq-JC8jWusQ@mail.gmail.com> <d3de69d6-f46b-fe0c-b6dc-8180864bd9b0@ietf.contact> <CABcZeBO15H=+ds0deqvtOzKvX+JvFzCn2pht3fcKYcp7df=UFw@mail.gmail.com> <52b08a1b-45e2-b03b-a0a8-12e55b56bfa8@ietf.contact> <CABcZeBOwZ3=pz=Xz1D3YwJ6_svTidt5azWDFnTwexsE508rmkA@mail.gmail.com> <ee313d5a-967b-c434-804c-097e4777ca20@ietf.contact> <CABcZeBP7-A52XPghkCWa7f15Xa1UvoHKujhNPzvoH+cP+McSWQ@mail.gmail.com> <9d22aa43-3524-e5b4-32f7-f9e6006c5485@ietf.contact>
In-Reply-To: <9d22aa43-3524-e5b4-32f7-f9e6006c5485@ietf.contact>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 15 Apr 2025 19:15:50 -0700
X-Gm-Features: ATxdqUHU7PvG36TUpI6MxHqsl4VMEgp2ralUQs7wiFm9bFIo1tn2z_F7YyIZ54M
Message-ID: <CABcZeBNGUWxKUpOY-5YwN7Tj29YAxJvVYy=PkKhk4oLnOASYfA@mail.gmail.com>
To: Henk Birkholz <henk.birkholz@ietf.contact>
Content-Type: multipart/alternative; boundary="000000000000575ead0632dbdf93"
Message-ID-Hash: LEPL3VXLKWLNCRIIGKAZHPVULC2CSN6I
X-Message-ID-Hash: LEPL3VXLKWLNCRIIGKAZHPVULC2CSN6I
X-MailFrom: ekr@rtfm.com
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
CC: Richard Barnes <rlb@ipv.sx>, Meiling Chen <chenmeiling@chinamobile.com>, "Liuchunchi(Peter)" <liuchunchi@huawei.com>, "nasr@ietf.org" <nasr@ietf.org>, IETF SAAG <saag@ietf.org>, Luigi Iannone <ggx@gigix.net>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [nasr] Re: [saag] Re: NASR BOF Follow-Up
List-Id: Network Attestation for Secure Routing <nasr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nasr/lzT68SnfWv6J6V3QC9p_BbJmOsY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nasr>
List-Help: <mailto:nasr-request@ietf.org?subject=help>
List-Owner: <mailto:nasr-owner@ietf.org>
List-Post: <mailto:nasr@ietf.org>
List-Subscribe: <mailto:nasr-join@ietf.org>
List-Unsubscribe: <mailto:nasr-leave@ietf.org>

On Tue, Apr 15, 2025 at 1:17 AM Henk Birkholz <henk.birkholz@ietf.contact>
wrote:

> Hi ekr,
>
> I apologize for mixing provenances... again! For me, dipping in into
> this thread occasionally, it is not easy to track data origin vs. data
> source without a napkin note.
>
> Both questions:
>
> "is it possible to determine that the configuration/policy of a device
> is acceptable in a fashion that does not expose that
> configuration/policy to a counterparty?"
>
> and
>
> "Is it practical to mechanically verify that a configuration is
> acceptable?"
>
> sound like really good questions to me. Personally, I am under the
> assumption that both of these questions are not RATS questions and maybe
> not even SEC area questions. They seem to me more like OPS area
> questions, right?.


Yes, I agree.

-Ekr




> Please chime in here on the SAAG list, if you think
> that was a weird thing to say! (Obviously, opsec is a thing, but I am
> referring the "mechanics" of the solution providing an answer to the
> questions).
>
> I also think that (from a RATS perspective) the answer to those
> questions is really interesting (as it could inform the exposure of RATS
> conceptual messages). Will these questions be worked on?
>
>
> Viele Grüße,
>
> Henk
>
>
> On 11.04.25 23:29, Eric Rescorla wrote:
> >
> >
> > On Fri, Apr 11, 2025 at 11:50 AM Henk Birkholz
> > <henk.birkholz@ietf.contact> wrote:
> >
> >     On 11.04.25 19:23, Eric Rescorla wrote:
> >
> >     Hi Ekr,
> >
> >     sorry for dragging you through this convo, but I think I now have a
> >     better understanding of your problem statement than before. Thanks!
> >
> >     As far as I am understanding it for now, the question is: "is it
> >     possible to determine that the configuration/policy of a device is
> >     acceptable in a fashion that does not expose that
> configuration/policy
> >     to a counterparty?" That question would be independent from "RATS
> >     Evidence" which was popping up in the thread before.
> >
> >
> > To be clear, that was *Richard's* question. My question was prior to
> that,
> > namely "Is it practical to mechanically verify that a configuration is
> > acceptable?"
> >
> > -Ekr
> >
>