IETF Logo Mail Archive

Re: [Rats] Attestation of implementation vs authenticity of service

"Salz, Rich" <rsalz@akamai.com> Mon, 03 August 2020 19:03 UTC

Return-Path: <rsalz@akamai.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 4C4063A1068 for <rats@ietfa.amsl.com>; Mon, 3 Aug 2020 12:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 mw5H8F6leaUE for <rats@ietfa.amsl.com>; Mon, 3 Aug 2020 12:03:28 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 E43DA3A1062 for <rats@ietf.org>; Mon, 3 Aug 2020 12:03:27 -0700 (PDT)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 073J2NLc008812; Mon, 3 Aug 2020 20:03:26 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=/G8DQbwjpTvege86/BQCwG1asSpzv9VKypPhbF8/heY=; b=ff+NALfRjZhVd7PPPcj+Y1RBBy5Wamt4lIjuKsybMDlmGCfrqFGWQbcJ+ZlJCRjY4bfa LY5x8sAgeNtn0INEFK2RXuH49D4f9S27aD3ukOdrB9Jgfx3skTxFIEZHx1wEnbZkwWCt r/6m7dZh9q42GdhSQl/ZI+bSq35iwUoRQZaxFKkkysrfhDRmAn4MqmJSxfIL6+8Ts1TT QC82LzaOgsdQX70rrpn6KwnkHnEPtH/J4oIAOy3nZ0xN8aa/ZvVZMMpWElsw/jCJaFuD VPbpPc0+jz/jEOczOMkK9Vp6o5nTfWZpkyL6QVuOnkr7QxXmnc9D1bfBvbswG6r8mQ9T 2g==
Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 32n6y3wh1y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 03 Aug 2020 20:03:26 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 073IohR8019531; Mon, 3 Aug 2020 15:03:26 -0400
Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint3.akamai.com with ESMTP id 32n3qxq373-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 03 Aug 2020 15:03:26 -0400
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 3 Aug 2020 14:03:25 -0500
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.006; Mon, 3 Aug 2020 14:03:25 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Laurence Lundblade <lgl@island-resort.com>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Attestation of implementation vs authenticity of service
Thread-Index: AQHWacguz/u1iJJ1nUmvdh+W841NEqkmzrkA
Date: Mon, 03 Aug 2020 19:03:25 +0000
Message-ID: <002D1F7F-4894-44B0-82E6-5EBD80C698E4@akamai.com>
References: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com>
In-Reply-To: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.38.20061401
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.114.156]
Content-Type: multipart/alternative; boundary="_000_002D1F7F489444B082E65EBD80C698E4akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-03_15:2020-08-03, 2020-08-03 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 mlxlogscore=960 adultscore=0 suspectscore=0 malwarescore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008030131
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-03_15:2020-08-03, 2020-08-03 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 mlxscore=0 adultscore=0 bulkscore=0 malwarescore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501 clxscore=1011 mlxlogscore=928 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008030132
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/sdBBB6Yx9E8Eju4IuJjU-NTLo9U>
Subject: Re: [Rats] Attestation of implementation vs authenticity of service
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: Mon, 03 Aug 2020 19:03:29 -0000

  *   Another way to look at this is from a certification / regulatory view. If the thing you're looking at is a candidate for implementation certification such as Common Criteria, FIPS, FIDO certification, then it probably lines up with device attestation. On the other hand, if the thing your are looking at lines up with regulation (e.g., banking regulation, GDPR,...) and to some degree OWASP<https://urldefense.proofpoint.com/v2/url?u=https-3A__owasp.org&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=i2HHx7M5shXvUZmbo2H9JWFNah1cQYR9QL8xSUTJHcw&s=D7ncLvRq-bcYsr722qYkwbNUSyi2i1Ap7rstjSY-zZ0&e=>, then it probably lines up with service authenticity.

That is a *very* interesting way to slice things; I’ll have to think about it more. Thanks!


  *   I think the RATS architecture document should probably have text that describes when attestation is applicable and when it is not, for example saying something like “attestation is not a replacement or augmentation for HTTPS/TLS"

Excellent point.  Doing so will likely avoid a round-trip with the security AD’s.

v2.23.0 | Report a Bug | By Email