Re: [Rats] I-D Action: draft-birkholz-rats-uccs-01.txt

Benjamin Kaduk <kaduk@mit.edu> Sun, 14 June 2020 21:27 UTC

Return-Path: <kaduk@mit.edu>
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 98F5F3A00B2 for <rats@ietfa.amsl.com>; Sun, 14 Jun 2020 14:27:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhbQm3Ox42L2 for <rats@ietfa.amsl.com>; Sun, 14 Jun 2020 14:27:39 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944D33A00B0 for <rats@ietf.org>; Sun, 14 Jun 2020 14:27:39 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05ELRY0s019678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 14 Jun 2020 17:27:37 -0400
Date: Sun, 14 Jun 2020 14:27:34 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Carsten Bormann <cabo@tzi.org>
Cc: Laurence Lundblade <lgl@island-resort.com>, rats@ietf.org, "jeremy O'Donoghue" <jodonogh@qti.qualcomm.com>
Message-ID: <20200614212734.GY11992@kduck.mit.edu>
References: <72AE6830-B424-47F1-BA3D-C694989300AF@island-resort.com> <4F64295D-E8B9-428F-9587-8D0D2C763582@island-resort.com> <99E5F53A-815B-4BFA-AEBB-5155D7E45D89@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <99E5F53A-815B-4BFA-AEBB-5155D7E45D89@tzi.org>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/FNq2y5ay-jro96-jrZaYdr8dSUw>
Subject: Re: [Rats] I-D Action: draft-birkholz-rats-uccs-01.txt
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Jun 2020 21:27:41 -0000

On Wed, Jun 10, 2020 at 01:53:57PM +0200, Carsten Bormann wrote:
> Hi Laurence,
> 
> > It seems better factoring to associate the security model with the use cases than with the data structure format.
> 
> There are many ways to (insert vegan version of “skin this cat”).
> 
> Generally, the IESG has not been happy with defining protocols without discussing their security, so UCCS will need some security considerations.  The pure admonition “write up your security considerations” makes a bad security considerations section.  Picking one use case (here: the one that motivates us to write this document now) seems like a good way to evoke the kinds of security considerations other application environments will have.

Depending on the IESG, you may also get asked to mention situations that
could cause big problems in use cases other than the one being considered,
even if they are non-issues for the specific use case in question, as a way
to avoid potential "gotcha"s for the future documents that provide
alternative use cases/analyses.

-Ben