Re: [Rats] comments on draft-birkholz-rats-uccs

Laurence Lundblade <lgl@island-resort.com> Fri, 07 August 2020 16:46 UTC

Return-Path: <lgl@island-resort.com>
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 59E3F3A0CCF for <rats@ietfa.amsl.com>; Fri, 7 Aug 2020 09:46:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 cuQB2729cjSC for <rats@ietfa.amsl.com>; Fri, 7 Aug 2020 09:46:13 -0700 (PDT)
Received: from p3plsmtpa12-10.prod.phx3.secureserver.net (p3plsmtpa12-10.prod.phx3.secureserver.net [68.178.252.239]) (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 A76853A0CC7 for <rats@ietf.org>; Fri, 7 Aug 2020 09:46:13 -0700 (PDT)
Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 45VUk3t4EbZIF45VUkbMKa; Fri, 07 Aug 2020 09:46:13 -0700
X-CMAE-Analysis: v=2.3 cv=E9CzWpVl c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=oumihVu1M68n9TQdrkcA:9 a=QEXdDO2ut3YA:10 a=gdVDRX3PWmuWimQ2:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <23B2F64A-A32D-4060-94FB-43D688105DFC@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C298B9C9-3922-4EE1-B726-86EEE8BFABBA"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 7 Aug 2020 09:46:12 -0700
In-Reply-To: <CAM+R6NUya3dgpXWC11qufhKE9BcSSzG9W2W7jGDxqyRdOcrtRw@mail.gmail.com>
Cc: rats@ietf.org, Jessica Fitzgerald-McKay <jmfitz2@cyber.nsa.gov>, Michael Jenkins <m.jenkins.364706@gmail.com>
To: Jessica Fitzgerald-McKay <jmfmckay@gmail.com>
References: <CAM+R6NUya3dgpXWC11qufhKE9BcSSzG9W2W7jGDxqyRdOcrtRw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfAOpPS8I07LPTmro4i6JjvdxvuJOMJRoLabdKkp4ia0ptSZtLy9/EbtR7GA+JGE+6WkU4zxQtn+tXwcRUBQtws9nkcU0g7mqpWBT9WVRogsZ+kWN/fyh NY4RFW89IQgFtQceccCzX6jn40b1iyC+8dIBxaYMtLe3XOCDemBi1qt37F3RgWuvNg2g5XcDTgxPwxS/s90EmX32m0qq+m6urIItz3+D4tMJyFAoGY+kuRZR 2vAw80j1CUJud6L/52yvkNRE5espPxBfwWIcOq51kK0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/TGd3SB5H6MTxVigDeRIuOE32sTI>
Subject: Re: [Rats] comments on draft-birkholz-rats-uccs
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: Fri, 07 Aug 2020 16:46:15 -0000

Seems to me that one of these is also characteristic of CWT/COSE (character of symmetric keys) and the rest are potentially true of CWT/COSE.

Personally, I don’t think it is the IETF’s job to explain to implementers how to correctly use a TEE, SE, HSM or other restricted operating environments. That’s not a job that can be completed in a protocol document. Most implementers working with TEEs and similar already have the rope and we can’t really take it away from them. When I went to intro to writing security considerations session at the last Montreal IETF, one of the main points was that IETF can’t really control what implementers do.

That said, I do think it is the job of the IETF to create protocols that can make use of TEE’s and the like.

As I’ve mentioned before, I think UCCS should have a very minimal discussion on security in-the-absence-of-CWT/COSE because it’s not really possible to cover it well. There’s too many implementation environment and use case specific issues. Jessica’s comment is an illustration of that.

LL


> On Aug 7, 2020, at 7:01 AM, Jessica Fitzgerald-McKay <jmfmckay@gmail.com> wrote:
> 
> Hi, UCCS authors,
> 
> Mike Jenkins and I reviewed the UCCS draft. Our comments are below. Happy to talk through any of them with the group.
> 
> Thanks,
> Jess
> 
> The intent of this draft is similar to the key concept of EST - use the authentication of the secure session connection. Most schemes build on this concept leave a lot of banana peels laying around, some of which we describe here. In general, this does not seem appropriate to the scope of RATS. We feel that COSE might be a more appropriate work group to think these issues through.
> 
> - If you're using a static symmetric key for authentication (as one might with highly-constrained devices), you can only authenticate a net, not an entity. The receiver cannot differentiate between authenticating the sender and authenticating itself.
> 
> - The authentication happens at the secure channel termination, not in the channel-contents-using application. It's important how the termination process vouches the authentication to the application. (In EST, this question is how the EST server vouches the requestor's identity to the CA server.)
> 
> - A TEE only helps if the TEE application can punch through the REE and set up the secure channel completely on its own. If the TEE relies on the REE to set up the secure channel, you might as well just operate in the REE.
> 
> - There is a comment at the end of the introduction (!) about transitioning back and forth between self-protected and channel-protected CWT, "in a well-defined scope". Define the security characteristics of that scope or get rid of the comment. You're handing someone an awful lot of rope there.
> 
> - The claims set should be treated as ephemeral by the recipient. It shouldn't be stored, and can't be forwarded except as data originated by the recipient. As soon as it emerges from the secure channel, it's no more valid or meaningful than any other piece of unprotected data in the application environment.
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats