Re: [Teep] Working Group Last Call for HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-TAM Communication

Dave Thaler <dthaler@microsoft.com> Thu, 02 April 2020 01:35 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 24BC13A08B3 for <teep@ietfa.amsl.com>; Wed, 1 Apr 2020 18:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 vVUnhoTZqNJB for <teep@ietfa.amsl.com>; Wed, 1 Apr 2020 18:35:18 -0700 (PDT)
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2126.outbound.protection.outlook.com [40.107.93.126]) (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 C3DE13A08AF for <teep@ietf.org>; Wed, 1 Apr 2020 18:35:17 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LzeTfMqJ3CikkKB71cVm1A4ptJ3oPsBm6StG3QH776DOlH2msu55pkHUBg8Sj2k4DaEWV2AnyOI5iw6zh3GuuU7wtoQD+RIJqtYdVm+1gwiMCMHoiSs77hcWUpRGJMjhZADKhYJcqq4OTLwbgbBWE0Sqd9Lm6cENgYJI2jT64Z7lXIv1fcf7WpbaGyXJ6i1800jDqgEDNsZuldhfk6OKSEPmGo0NckMNQtYtW8mFt5TCY7VhToDgC1UBZVaAmzxcrVheS8O7fURRGZEdbeiuziStQ7+g24xP560E/6Vl775r9xnUDi20wfMlGRxoBXQHgMDsIa6YRzaBFdxXwPfeiQ==
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=P+6CRLLVuov0SHCQOs1sOhU5GoZtW7IIMxk7E0m22iE=; b=NNKMkMdyYDrZwnY7DW8+5pC9sUQHq05cxBmusbY1MvCp3xrpMps9wjZVfSITrqg3Cm4h7vZm5MQ4pmWqR8Fj98t7FYsuEIe+C2MkLhsKv5wuERVKTa7NnxSc/tSzoYFrhUCtqKz4P50+h8Bhq2lOajwjORSaPrSWXkJC8DxVLTz6vgx6ZZB2U69Rz4jnbCWs52j6x3vAU4VYSNEYkKcyzhMTT2+RL4cohafoTChj/hwEdrL/p1nl/IEA9pFbOXPfAkeGgyfAJbLFNiB7aoqflF3th5voLHJpzqE18xKaO3ogi6KRFfC1G83SiVF9CJ8lhqvOPC2KbTOU1j3v1+pSEQ==
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=P+6CRLLVuov0SHCQOs1sOhU5GoZtW7IIMxk7E0m22iE=; b=iglI94UGs9ORDfNZwsPZfJkV8OtN7smw+K1vM5KOr9OnfIyplZJwKQ9pmj+iHMv3AY3Npxd5iSdcB2kHIaAhLCnNTumRV1Tp+gdbzJNka17N18+v9qvnO2jt/iqp/+XcfP52+MT5wDVGB/xncOUQvO6SI03/Zp9gAXMBK5bMQtU=
Received: from BL0PR2101MB1027.namprd21.prod.outlook.com (2603:10b6:207:30::33) by BL0PR2101MB1028.namprd21.prod.outlook.com (2603:10b6:207:34::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.0; Thu, 2 Apr 2020 01:35:15 +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; Thu, 2 Apr 2020 01:35:15 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: "teep@ietf.org" <teep@ietf.org>
Thread-Topic: [Teep] Working Group Last Call for HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-TAM Communication
Thread-Index: AdYIjsWAkp4hHTTyQpSZ0l0sLMZy8g==
Date: Thu, 02 Apr 2020 01:35:15 +0000
Message-ID: <BL0PR2101MB102751E84CB7D3F92D454AD5A3C60@BL0PR2101MB1027.namprd21.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:11d:e3f9:9ab6:60ec]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 19697790-861b-477d-d70e-08d7d6a61869
x-ms-traffictypediagnostic: BL0PR2101MB1028:
x-microsoft-antispam-prvs: <BL0PR2101MB1028477957C5E6C36EC3F907A3C60@BL0PR2101MB1028.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0361212EA8
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)(39860400002)(136003)(346002)(366004)(376002)(2906002)(186003)(86362001)(9686003)(7696005)(71200400001)(8936002)(966005)(33656002)(53546011)(6916009)(6506007)(55016002)(10290500003)(82950400001)(8990500004)(66556008)(81156014)(81166006)(66476007)(5660300002)(8676002)(76116006)(64756008)(478600001)(52536014)(66446008)(82960400001)(316002)(66946007); 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: t6+SyVawpDFq1XKwXsWDu2QrHn65/02+IbwwLAZ3XDbQQbghQPeabSWvPKPCmW2zvtAIIw9RtmClRX/6oBzh3B/EIs4jlZeR50SByOL2MmCwUJQzF2qrecwJOnJZLtQLqKyESZEGa0WiYpoGtLmA906BMMZB04uzUHccwxM4Ykic/os+1JTsVd10olwNAIK76axxAc4Hm3s9T/LYSGAbJfsDJjKmCt+IDi2WO3ctWdiwB8QPVHv29ECPstBFD5U7XbodpuB+Ue+cv+1/DJmlkAb/3NvXP9vwvyTGKFJFIvgPjE+qqNvMuli4LbIZ1rvoKW7lx1v9PXbG+gE+a6CHxZyr8IBjD30dZsfEzDXScOculseLeSATmJ/k8FeVZJfPgCDjiS7a9h1cZA/FUIJn4K1AVqBWe1ssD4H8Vo0fm+nqWlYqMPC0oy/dA5yhwqyZStR8Pjj/KpTql0lBB0kwW3KLVNm4hqU8s6C8dKy8Ncvl9gjk4AFTz0idAP1HE7Oj+o/UIW1hN71vIdhmRmn4Cw==
x-ms-exchange-antispam-messagedata: ln1VDf7Nyj0sKI+YOk1siLMzrVI915yc8DrqLH6MRINF5pHLPuSHHVa3CToksyrMMjSNHEJkP8+CQd6QKd6QqX9XW/hlxuuyo+DMyjsRFFD/cwhuwanzpEBq04Jvgt0H8ekY8ygy+Xcs6Dt6z9kBX6Tl+aqJ0q4ckRZslM/ytXuqTPUS5ovBDOxqsCy257txy1LujSxiFDVRFe/A8gVK7g==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 19697790-861b-477d-d70e-08d7d6a61869
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2020 01:35:15.7549 (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: tjawmVXI2Akww94QafDeQdeo8+LyN7UnTRLhw4jMKcW/grA9CFY/1LZrr3daNWVVBoneB3ROtCIPq5Ls34Jly4mYFTR4SSiYwvr+wo6UgkI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1028
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/hxxA_ELpAfTOxeUP-Tz9tsfX5OA>
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: Thu, 02 Apr 2020 01:35:21 -0000

As noted in my earlier response, I reached out to Mark Nottingham for his advice on Tiru's points 4 and 7.
Below is his response, forwarded with his permission (thanks Mark!).

-----Original Message-----
From: Mark Nottingham <mnot@mnot.net> 
Sent: Wednesday, April 1, 2020 5:46 PM
To: Dave Thaler <dthaler@microsoft.com>
Subject: Re: bcp56bis advice

Hey,

> On 1 Apr 2020, at 1:43 pm, Dave Thaler <dthaler@microsoft.com> wrote:
> 
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-httpbis-bcp56bis-09%23section-4.3&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C9fa1c2badbf146a12c4908d7d69f36c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637213851618009265&amp;sdata=n9bSri4tGPXgdGCpz7kQYxoxWNYbpR9sADTl%2BVMdpVQ%3D&amp;reserved=0 says:
> >   o  Certificates - Applications using HTTP should specify that TLS
> >      certificates are to be checked according to [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.

I'd probably handball this to the Security Directorate or similar; we didn't go there because it's not HTTP-specific.

> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-httpbis-bcp56bis&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C9fa1c2badbf146a12c4908d7d69f36c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637213851618009265&amp;sdata=LOP11zXBPJCtCQvv36EbkhOEHuf%2BEATfa3igtBooLaY%3D&amp;reserved=0 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.

It does. FWIW I don't think it's harmful to say "in this situation, servers should use status code X, because that's the most appropriate one for those semantics." What you want to stay away from is saying "clients receive status code X can infer Y." Unfortunately, the difference is subtle and easily misread.


> 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.

FWIW, I don't think it's necessary to reference 56bis unless you're relying on it for security considerations or the like.

Cheers,

--
Mark Nottingham