IETF Logo Mail Archive

Re: [EAT] Security Levels (seclevel): why "restricted"

Jeremy O'Donoghue <jodonogh@qti.qualcomm.com> Wed, 27 June 2018 09:12 UTC

Return-Path: <jodonogh@qti.qualcomm.com>
X-Original-To: eat@ietfa.amsl.com
Delivered-To: eat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1EF130F3E for <eat@ietfa.amsl.com>; Wed, 27 Jun 2018 02:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
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 GbmlrppNvhTL for <eat@ietfa.amsl.com>; Wed, 27 Jun 2018 02:12:23 -0700 (PDT)
Received: from alexa-out-ams-02.qualcomm.com (alexa-out-ams-02.qualcomm.com [185.23.61.163]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B44130EA4 for <eat@ietf.org>; Wed, 27 Jun 2018 02:12:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1530090742; x=1561626742; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1IiUogFTkLDzfwT+cKoCoBw/W9XyEbbzL00KlW3jnAs=; b=DtR5Oru2fjvLUAhXhhhOOPvpnqt4+nezpkRFEmmASYOayE/sJ+kp71tj hwHoKEtOl3RXaH0IRetF0HVfBnaZeVvg3sZcrHqX0pv5jpXNX2yy8+RRh LqrRJVC3Ue3gV7DUlC4al/AOhdVCcN5lj5wDh4OUBUJPMzbAlyGIjtRJl k=;
X-IronPort-AV: E=Sophos;i="5.51,277,1526335200"; d="scan'208,217";a="667888"
Received: from ironmsg03-ams.qualcomm.com ([10.251.56.4]) by alexa-out-ams-02.qualcomm.com with ESMTP; 27 Jun 2018 11:12:21 +0200
X-IronPort-AV: E=McAfee;i="5900,7806,8936"; a="3482953"
Received: from euamsexm01a.eu.qualcomm.com ([10.251.127.40]) by ironmsg03-ams.qualcomm.com with ESMTP/TLS/AES256-SHA; 27 Jun 2018 11:12:21 +0200
Received: from euamsexm01a.eu.qualcomm.com (10.251.127.40) by euamsexm01a.eu.qualcomm.com (10.251.127.40) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 27 Jun 2018 11:12:19 +0200
Received: from euamsexm01a.eu.qualcomm.com ([10.251.127.40]) by euamsexm01a.eu.qualcomm.com ([10.251.127.40]) with mapi id 15.00.1365.000; Wed, 27 Jun 2018 11:12:19 +0200
From: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>
To: Laurence Lundblade <lgl@island-resort.com>
CC: "eat@ietf.org" <eat@ietf.org>
Thread-Topic: [EAT] Security Levels (seclevel): why "restricted"
Thread-Index: AQHUCUFtq4I8PLW6JUqrWsdW00FIYKRsUZeAgAdoQwA=
Date: Wed, 27 Jun 2018 09:12:18 +0000
Message-ID: <6760F42C-6AD1-430B-BB28-6912EA47E68D@qti.qualcomm.com>
References: <99A5F020-7CAA-4E11-95F5-C522CE6FD75C@qti.qualcomm.com> <B4993F47-435E-494A-8682-87FFB10D378A@island-resort.com>
In-Reply-To: <B4993F47-435E-494A-8682-87FFB10D378A@island-resort.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.8.2)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.251.42.152]
Content-Type: multipart/alternative; boundary="_000_6760F42C6AD1430BBB286912EA47E68Dqtiqualcommcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/0jGBlmrm7BHFlwFzKK7ftR4x3Ok>
Subject: Re: [EAT] Security Levels (seclevel): why "restricted"
X-BeenThere: eat@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: EAT - Entity Attestation Token <eat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eat>, <mailto:eat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eat/>
List-Post: <mailto:eat@ietf.org>
List-Help: <mailto:eat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eat>, <mailto:eat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jun 2018 09:12:26 -0000

I'm open to discussion on names. The main argument I am making is that we currently have four claims levels and three seems better aligned with industry practice - i.e. we should not distinguish between "restricted" and "restricted secure".

Jeremy

On 22 Jun 2018, at 17:05, Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>> wrote:

Also, here’s<https://developer.android.com/training/articles/security-key-attestation#certificate_schema_securitylevel> Android’s security level distinction for Android attestation. They call their levels “Software” and “TrustedEnvironment”. This lines up with Unrestricted and Restricted.

LL


On Jun 21, 2018, at 2:22 AM, Jeremy O'Donoghue <jodonogh@qti.qualcomm.com<mailto:jodonogh@qti.qualcomm.com>> wrote:

I have been thinking about the seclevel claim, and while I agree that the claim is not related to security certification as such, the more I consider the semantics, the more I struggle with the difference between "Unrestricted" and "Restricted" security, since it seem to me that there is no practical difference in the security level that can legitimately be claimed between these cases - anecdotal evidence of security breaches in many devices which would meet the "Restricted" definition.

My suggestion, therefore, would be to remove "restricted" and perhaps to replace the claim names:

- "Basic" to replace "Unrestricted";
- "Substantial" to replace "Secure Restricted";
- "High" to replace "Hardware".

This also seems to align with emerging views on describing security (FIDO, eIDAS for example) which is trending towards describing security at one of three levels, which are generally couched in terms such as "basic", "substantial", "high".

Jeremy
_______________________________________________
EAT mailing list
EAT@ietf.org<mailto:EAT@ietf.org>
https://www.ietf.org/mailman/listinfo/eat

v2.23.0 | Report a Bug | By Email