Re: [Teep] Working Group Last Call for HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-TAM Communication
Dave Thaler <dthaler@microsoft.com> Wed, 01 April 2020 02:38 UTC
Return-Path: <dthaler@microsoft.com>
X-Original-To: teep@ietfa.amsl.com
Delivered-To: teep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BEB3A00C4 for <teep@ietfa.amsl.com>; Tue, 31 Mar 2020 19:38:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 Dv_cV9Ybl2jF for <teep@ietfa.amsl.com>; Tue, 31 Mar 2020 19:37:59 -0700 (PDT)
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2120.outbound.protection.outlook.com [40.107.92.120]) (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 073B93A00C0 for <teep@ietf.org>; Tue, 31 Mar 2020 19:37:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NVUGbN18dWU8ZoBPVEsFJGMK8auqqXIEmSvWJFeU+npBgLtTsRdaOh/eOW9BgxgEWsAkXaUTgjyRiGJq1MSK0Pe0dsXBL1y2y0MFYY4rskuQquuFaObWJ/AineOwiIBQ3iJ2MeQO9bL/8qORlK/6IGrm5zdQm7xdutSnp+6eA4UCjCF4h9VN6+2rSpLPd7th1NszDhpym/LVGp1xNT9xQZAX573sz02Pv4lkqBjhDKXsscRi3mrvh8ABlRIBI7d3uGCIyPnBelbS6iBEkm9G5V5k/n3XoX+fZUo4UdD724soerva7QWLzRLmV2SUgGn5QfrFotshy1zaTXyk3hjP8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lBAwxkCm29Ziesuf2QYdledYhpD/mHuG/P2NlZ4v/fI=; b=lyVakLl9vFEYSQL70sHs5BN1qs2Lrlk8wZ5Ntuh3wlkUo//MeZpsH2wcB0E/V31pIq8mWS/M1QLH1PF9sqQ6cu4+E4ImxibjYOflX6dSqC6LN70SNRTx0ZKToLuULZvOHFbIjL3zpw8L6B7m5Cd1v/nQKJZoxTR1oQ9fHRf7TarKfhX5BDhFxqdAuumvn3w1Oc/E5+M4hxXLPJvG8XbRMe5FkF0xqbzfsbr0gFjKi9mEvitIX0mKOWkSOT/GMJHEoamaIbGGB7qUcOmWRxoz3v+rdYIlZqj9wlu+ZANeRQzsLybjb3ygO/9fp5Nzds4yICji20ObGSsJUBaEbiDO5A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lBAwxkCm29Ziesuf2QYdledYhpD/mHuG/P2NlZ4v/fI=; b=Ni+PURVSBDfWuQIUf5o8gVYe3uwHGkm2f6Z2NiOD2iLTedYo9PmNFNUzm3PAih2K5Qn+f76OPPU0Iiok9D3jm3U1jWgR9k9VRkK/eyujPn7Z0u/R8FTdtDvhjHT6Q1OQVjpW4j05rdFtPENfZmNWiEr1jxRAoRqsjVFj3QIxHFI=
Received: from BL0PR2101MB1027.namprd21.prod.outlook.com (2603:10b6:207:30::33) by BL0PR2101MB0961.namprd21.prod.outlook.com (2603:10b6:207:30::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.0; Wed, 1 Apr 2020 02:37:53 +0000
Received: from BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::e5f4:bd2b:d304:bfc9]) by BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::e5f4:bd2b:d304:bfc9%4]) with mapi id 15.20.2878.010; Wed, 1 Apr 2020 02:37:53 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
CC: "teep@ietf.org" <teep@ietf.org>
Thread-Topic: Working Group Last Call for HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-TAM Communication
Thread-Index: AdXgu0iSExhAZRZISA2YiaXw3QSuswZ06BMAA04PiqA=
Date: Wed, 01 Apr 2020 02:37:52 +0000
Message-ID: <BL0PR2101MB1027EC4E9CBA532DEF0099E8A3C90@BL0PR2101MB1027.namprd21.prod.outlook.com>
References: <CY4PR1601MB12540E3731269EF636F9D5B1EA180@CY4PR1601MB1254.namprd16.prod.outlook.com> <CY4PR1601MB1254B12910386A4EB149D35EEAF80@CY4PR1601MB1254.namprd16.prod.outlook.com>
In-Reply-To: <CY4PR1601MB1254B12910386A4EB149D35EEAF80@CY4PR1601MB1254.namprd16.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com;
x-originating-ip: [2601:600:9780:16f0:2c3c:d263:476c:d2f7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 276666ef-18ce-4b19-6248-08d7d5e5ad9f
x-ms-traffictypediagnostic: BL0PR2101MB0961:
x-microsoft-antispam-prvs: <BL0PR2101MB0961AB3467B925FD8B42A2C7A3C90@BL0PR2101MB0961.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03607C04F0
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR2101MB1027.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(396003)(366004)(39860400002)(376002)(346002)(136003)(33656002)(86362001)(6506007)(81166006)(478600001)(66574012)(10290500003)(6916009)(7696005)(53546011)(5660300002)(966005)(8990500004)(8676002)(81156014)(2906002)(71200400001)(66556008)(76116006)(66446008)(66476007)(4326008)(82950400001)(8936002)(186003)(66946007)(55016002)(9686003)(64756008)(316002)(52536014)(82960400001); DIR:OUT; SFP:1102;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: uNj7G9dc/6x8Em2dxB4zQtlLwtLBtX5UbLysawJ4PUJMcVlQfGVzt1d8uNFNP/oGQtCSaumcZFAG+O5jNI1d/xQub3aADbT4NyT/e4kJ78zxTCMpJW+HtWNL+Gl0xm8GBlpjDYdM6ytHY1TDgKppoOCaSU51dB0NlHTFul+y2P9Gn/xQrp7Xx0/YtCJxsfkLCuDjDUGSk9jA38NlAjmpKH6KT/UAv/X/ZwxAsNbLqlY1uZSNebSTP4mGpXXH068IcGM7yROu3IwYW1gXiXCXr8Wbh8PrKkNfXKRXam9zjMg3vHjR4bNbRtj49UaSGyS8QgHi+4kudvHkhvT/98JLcLUAXoA2Ek5N6RFfbW9+9TyyGmu7qbhTcoa8pFSWpop90VudHoBTN5m/0tP2DtM9DpRdKwFlkVor4GW7Fi3h5slwRyxBDFi2WWTpGZFlUs+zg73b2FjzUEz2d/BI95YYxOo8e6esBqIeJQAc60hBmkUU+8Ajg7XH6EBz8ZwTob0SUDAef4YvOZi7n9NYrPNggA==
x-ms-exchange-antispam-messagedata: 94DHESxbtGfOXJu7LjoXkFEGEi9BJ5pgHQ/MyTt7nvKauZfOFfWL8XFre+yKiwfs5aDWH939HDoSocv/KRgHvUtq0hBPAGN/7+xzrjiyhTvBnbx046N+BxgEufxf6jGAEKjm3PDT+xNg9/25QGrKGv1BytF8b7fe3ks23ahEEwcUlYMOtl+Oa6pArAVkqwSaEbnihF0EG4k2gPZ7A2rOXA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB1027EC4E9CBA532DEF0099E8A3C90BL0PR2101MB1027_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 276666ef-18ce-4b19-6248-08d7d5e5ad9f
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2020 02:37:53.2945 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: iZQ+C9PIDINhjJZlub2TFU6cNlXJAunKDzg2K/gBDJwCRlWggsv2wvgJgkFSBweSQ7B+nE/o01o20dyJXbYmUEKd9VUHQcbOCXp+IrSKBYg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB0961
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/yD7CeO6Y8v8hdBEOaDafeicyzl4>
Subject: Re: [Teep] Working Group Last Call for HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-TAM Communication
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <teep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teep>, <mailto:teep-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teep/>
List-Post: <mailto:teep@ietf.org>
List-Help: <mailto:teep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teep>, <mailto:teep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2020 02:38:03 -0000
From: TEEP <teep-bounces@ietf.org> On Behalf Of Konda, Tirumaleswar Reddy Sent: Saturday, March 14, 2020 11:05 PM To: teep@ietf.org Subject: Re: [Teep] Working Group Last Call for HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-TAM Communication Hi Dave, Comments and nits below: 1) TAMs are reachable on the Internet, and Agents are on networks that might be behind a firewall, so that communication must be initiated by an Agent. Thus, the Agent has an HTTP Client and the TAM has an HTTP Server. Nit> Agents can also be behind NAT (and not reachable on the Internet). Updated (in forthcoming -06) 2) Agents are reachable on the Internet, and TAMs are on networks that might be behind a firewall, so that communication must be initiated by a TAM. Thus, the Agent has an HTTP Server and the TAM has an HTTP Client. Comment> What is the use case of hosting TAMs not reachable on Internet ? Answered in https://github.com/ietf-teep/otrp-over-http/issues/2 https://datatracker.ietf.org/meeting/106/materials/slides-106-teep-sessa-enarx-a-teep-use-case-00 https://datatracker.ietf.org/meeting/106/materials/slides-106-teep-sessa-teep-over-http-00 slides 7-9<https://datatracker.ietf.org/meeting/106/materials/slides-106-teep-sessa-teep-over-http-00%20slides%207-9> and also the minutes from IETF 106 when the use cases were presented. Conclusion, as I understand it, was that this draft is not responsible for answering your question since it's out of scope. The document just needs to say enough to say it's out of scope, which is the intent of the current text. Comment> If Agent is reachable on the Internet, it can be subjected to various attacks (e.g., DDoS). That's an issue for anyone writing the transport for that use case to deal with :) 3) Nit> Please add a reference to QUIC. Comment> Why refer to QUIC when it is not discussed in the document ? Added informational reference, and mention in section 1. 4) When HTTPS is used, TLS certificates MUST be checked according to [RFC2818]. Comment> RFC2818 refers to TLS 1.0 and several of its sections are outdated in comparison with TLS 1.3. Comment> For example, when TLS 1.3 is used, is 0-RTT supported ? Comment> RFC2818 refers to RFC2459 and is obsoleted by RFC5280. Comment> What TLS versions should the client and server support (If TLS 1.2 needs to be supported, please add text discussing the privacy and security implications) ? https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-09#section-4.3 says: > o Certificates - Applications using HTTP should specify that TLS > certificates are to be checked according to [RFC2818<https://tools.ietf.org/html/rfc2818>] when HTTPS > is used. Which is what this doc says. Do you think that bcp56bis is deficient in not asking app protocols to say what TLS versions should be supported? If so, you should provide that feedback soon (if you didn't already) since it's listed as WG Consensus: Waiting for Write-Up I'm hesitant to add any text here without a specific recommendation from that doc since I'd probably get it wrong. Leaving it silent, on the other hand, means people should get the answer from bcp56bis, which is referenced in the Security considerations section. I don't know if that's sufficient or not, but would want advice from someone like Mark. 5) HTTP is susceptible to several attacks including pervasive monitoring, any specific reason to support HTTP ? For debugging purposes before putting it into production. Also some argue that since TEEP already does its own security layer inside, the value of multiple layers of security Is diminished, especially if you're a constrained node looking to reduce code size. The text in the security consideration Section is targeted at such folks explaining why they should consider HTTPS anyway. (That may or may not convince them but that's their call.) 6) If the TEEP implementation already had a cached TAM certificate that it trusts, it could skip to step 9 instead and generate a QueryResponse.) Comment> I don't get the above line, none of the steps discuss caching of TAM certificate. Caching of certificates would be a TEEP protocol layer thing, not a transport layer thing, so you'd get the answer from the TEEP protocol spec. Here it's referring to the OCSP_DATA in the QueryRequest in section 4.1 of draft-ietf-teep-protocol. The fact that the "caching" is not mentioned in that spec is a valid issue for that spec to fix. Updated text here to reference OCSP_DATA. 7) If any error occurs where the TEEP/HTTP Server cannot get a message buffer (empty or not) back from the TEEP implementation, the TEEP/ HTTP Server generates an appropriate HTTP error response. Comment> Any specific reason for not specifying the error code ? Yes. There are many possible error reasons and legal HTTP error codes for them, so it's up to the implementation to pick an appropriate one based on HTTP specs. https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis says: Instead, applications using HTTP should define their errors to use the most applicable status code, making generous use of the general status codes (200, 400 and 500) when in doubt. Importantly, they should not specify a one-to-one relationship between status codes and application errors, thereby avoiding the exhaustion issue outlined above. FYI, when MNot reviewed this spec (as author of bcp56bis) he said it looked ok. 8) Although TEEP is protected end-to-end inside of HTTP, there is still value in using HTTPS for transport, since HTTPS can provide additional protections as discussed in Section 6 of [I-D.ietf-httpbis-bcp56bis]. Comment> Please elaborate on end-to-end protection and how to defend from attacks like MiTM modifying the HTTP headers, replay attacks etc. I'm going to push back on this... can you elaborate on why you think there's something specific to this document here, beyond what's stated in the reference (plus of course the fact that TEEP is protected end-to-end inside of HTTP)? Comment> Why is ietf-httpbis-bcp56bis an Informative reference ? Fair question. I don't have a strong preference either way. Current answer is because it's not used in any sentence in a normative way. Comment> What are the privacy implications of using HTTP ? See Section 6.1 of bcp56bis. Comment> Why would the TAM administrator choose HTTP instead of HTTPS ? For debugging purposes before putting it into production. 7) IANA section needs to be updated with "application/teep+json" content-type. No, the media type is up to the protocol spec, not the transport. It's in the TEEP Protocol's IANA consideration section. This is stated in section 4 of this draft where it says: Ø (replacing Ø the content type with the relevant TEEP content type per the TEEP Ø specification): Dave Cheers, -Tiru
- [Teep] Working Group Last Call for HTTP Transport… Konda, Tirumaleswar Reddy
- Re: [Teep] Working Group Last Call for HTTP Trans… Russ Housley
- Re: [Teep] Working Group Last Call for HTTP Trans… Konda, Tirumaleswar Reddy
- Re: [Teep] Working Group Last Call for HTTP Trans… Dave Thaler
- Re: [Teep] Working Group Last Call for HTTP Trans… Dave Thaler
- Re: [Teep] Working Group Last Call for HTTP Trans… Dave Thaler
- Re: [Teep] Working Group Last Call for HTTP Trans… Benjamin Kaduk
- Re: [Teep] Working Group Last Call for HTTP Trans… Dave Thaler
- Re: [Teep] Working Group Last Call for HTTP Trans… Benjamin Kaduk
- Re: [Teep] Working Group Last Call for HTTP Trans… Konda, Tirumaleswar Reddy