[secdir] Re: [Last-Call] Secdir last call review of draft-ietf-asdf-sdf-18

Magnus Nyström <magnusn@gmail.com> Tue, 28 May 2024 17:04 UTC

Return-Path: <magnusn@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50F7C1CAF43; Tue, 28 May 2024 10:04:30 -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, FREEMAIL_FROM=0.001, 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_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=gmail.com
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 NRuz3_wnuLSt; Tue, 28 May 2024 10:04:30 -0700 (PDT)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 02662C1CAF38; Tue, 28 May 2024 10:04:29 -0700 (PDT)
Received: by mail-il1-x12b.google.com with SMTP id e9e14a558f8ab-3745ccd9695so4696995ab.3; Tue, 28 May 2024 10:04:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716915869; x=1717520669; 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=hWtiLHLaeNRhfNEuxsQYjSgY1qEtJPMjsBVcldpdfzA=; b=YrVpOfUDhwTiIAvfAifIAB/Xjk/lro5RF+Roe4Koc0T7tNboMcc6gZjRqEBXZKKAj+ BmKX7/Kj72EPFUfEDq6lLfUToy6mxNrWnroLD3zAH5s2OqpjxjQKYq7K1HGaPUcTL8E0 LJuuLtAUwsF9lts7Kju6c2VIczGsFU7+qgyTv7MgfxW0eUkv6fvlgKWeqgGMwokEafRj sbvZbeQK2TleRb6vYGwEXBmyubvymsjkG24MTYEvH9c1LIL9P9UFoY2/NNsQD6VwDWG/ +CqKnF7ixZAWb3Gk8db9bNKWd9/ERbAchu9VzblI1xH0XNdojT+iyRtn6YgHxqPTXuq/ po4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716915869; x=1717520669; 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=hWtiLHLaeNRhfNEuxsQYjSgY1qEtJPMjsBVcldpdfzA=; b=mt5E7lptw/r1/1Imc/6cDl33w0PVbLlU3hL04yemBQ1Z80y3DjxK4DGGndCcvI6O72 4Y824BT4bo7QdXgQBXXgcHhw4J5p/9bRNMPuAs0wsxsAI84lDN3htYAIQuKG8eIW+x5T x34yH5MYG7lxQMvfUDO0Y+AntU82qYhGd4YnA+Zr+74YL6KZQrAdW5xq43plVdE5w0Lb Ldp25msTuEc6lceMy9/ns/Ic+NivRsqOOMqpfYEWfLeaG0SSiFHHX3plzAT9d4iCorsh MR+FVqbstFAY3lYyq5lF3vPB9q7eRTdGp3T2qjOrZYBBQZshHkdWQEPnkzoy7qqmF2wy rO2A==
X-Forwarded-Encrypted: i=1; AJvYcCWWFiN4JRUWCpDA+kydiI/m1qeiCZthimqW4Z0Ti5UFKjFLpq7sM+6BvS8waFVT7iD4z/b6xIMwrOjqu6EDe+fL/ZrTpYzkcwRLdklK9G0xR/zaavwgp850isnhWjsECCyqTX5u3KrHkkjMztFIDZ08k8JQ
X-Gm-Message-State: AOJu0YwHUaR/f5leFh4B9i4iofNTLD2WPv8CLqkU2dnkuV0WBf4CC/r9 N1aIkfnSq+fjgkUX83WF9FIE9aJEGIQzq68TQZWhUzgozy11HhLBiMnutxRzepAuQnZnwcAwkmi VvJxHR9d9HvI66ySGYxow2nCejQg=
X-Google-Smtp-Source: AGHT+IGJVqwhWQl7A1GXqCQutu57wolYBd2E1sVVXbKVbLKj2kmbuh0yY2/0rifkCJHmu0zkO1NUPurMrlmXhCGkMf4=
X-Received: by 2002:a05:6e02:1a24:b0:371:9a33:85df with SMTP id e9e14a558f8ab-3737b31b857mr142078975ab.19.1716915868839; Tue, 28 May 2024 10:04:28 -0700 (PDT)
MIME-Version: 1.0
References: <171687277928.58506.15548370459995846366@ietfa.amsl.com> <FAFF4355-359E-4436-BAE5-9CFB206ED70C@tzi.org>
In-Reply-To: <FAFF4355-359E-4436-BAE5-9CFB206ED70C@tzi.org>
From: Magnus Nyström <magnusn@gmail.com>
Date: Tue, 28 May 2024 10:04:17 -0700
Message-ID: <CADajj4anBnFQxznan-uE73ZgV4BmeEBtY=V0S2cpk9_jfZMXYw@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Content-Type: multipart/alternative; boundary="00000000000078bc2a061986a06b"
Message-ID-Hash: GCEES37IWHDAQL6YP7H6WZBOPEOHAJX7
X-Message-ID-Hash: GCEES37IWHDAQL6YP7H6WZBOPEOHAJX7
X-MailFrom: magnusn@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-secdir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: secdir@ietf.org, asdf@ietf.org, draft-ietf-asdf-sdf.all@ietf.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [secdir] Re: [Last-Call] Secdir last call review of draft-ietf-asdf-sdf-18
List-Id: Security Area Directorate <secdir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/moswd7oL2dr1IUnh-kpHgi9SFrU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Owner: <mailto:secdir-owner@ietf.org>
List-Post: <mailto:secdir@ietf.org>
List-Subscribe: <mailto:secdir-join@ietf.org>
List-Unsubscribe: <mailto:secdir-leave@ietf.org>

Thanks Carsten. It could be that I am not familiar with the terminology
used in the SDF area, but "provenance" is not a term that I immediately
would have recognized as covering authenticity and integrity. This is just
a  suggestion, but perhaps you could consider changing

FROM

Implementations need to ascertain the provenance (and thus authenticity and
integrity)
TO

Implementations need to ascertain the authenticity and integrity (i.e.,
provenance)

But, leaving that to you and the team to decide.

No concerns from my side,
/M


On Mon, May 27, 2024 at 10:56 PM Carsten Bormann <cabo@tzi.org> wrote:

> Hi Magnus,
>
> thank you for this review.
> A couple of quick comments to your specific items:
>
> > - The Security Considerations section mentions the possible need for
> > confidentiality of an SDF model ("There may be confidentiality
> requirements on
> > SDF models, both on their content and on the fact that a specific model
> is used
> > in a particular Thing or environment"). Couldn't there also be a need for
> > integrity/authenticity of a given SDF model? The document is silent on
> this.
>
> Actually, we use (twice) a much stronger word: provenance.
> This combines integrity and authentication with some appraisal (or at
> least policy) of how the data from the authenticated source can be used.
> We are not pointing to a specific mechanism here, as that is likely to be
> ecosystem specific.
> We could, however, explicitly remind the reader that provenance has
> integrity and authenticity as a prerequisite.
> A minimal change in:
>
> https://github.com/ietf-wg-asdf/SDF/pull/157
>
> > -
> > Related to the previous point, was it ever discussed to allow for an
> integrity
> > or authenticity value accompanying or being part of an SDFThing instance?
>
> Given the role of SDF as a hub format, SDF needs to be agnostic to the
> kinds of integrity protection and authenticity that is used with it.
> Embedding a model into an SDFThing instance is certainly one way to provide
> this information in a way that could make use of protection already
> available for the Thing in general.  It is more likely, though, that a
> Thing will provide a reference to its model that is stored somewhere else.
> That would be described in a model using an extension such as that proposed
> in [1] (if it is offered as an affordance from an instance) or possibly
> [2].  (These are likely to become WG documents after the current
> rechartering.)
>
> [1]: https://datatracker.ietf.org/doc/draft-bormann-asdf-sdftype-link/
> [2]: https://datatracker.ietf.org/doc/draft-laari-asdf-relations/
>
> Grüße, Carsten
>
>

-- 
-- Magnus