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

Benjamin Kaduk <kaduk@mit.edu> Thu, 02 April 2020 01:40 UTC

Return-Path: <kaduk@mit.edu>
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 651BB3A0900 for <teep@ietfa.amsl.com>; Wed, 1 Apr 2020 18:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Qh0lSEDJH0E7 for <teep@ietfa.amsl.com>; Wed, 1 Apr 2020 18:40:42 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5250B3A08FE for <teep@ietf.org>; Wed, 1 Apr 2020 18:40:42 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0321eVPf000552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 1 Apr 2020 21:40:33 -0400
Date: Wed, 01 Apr 2020 18:40:31 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>
Cc: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>, "teep@ietf.org" <teep@ietf.org>
Message-ID: <20200402014031.GC50174@kduck.mit.edu>
References: <CY4PR1601MB12540E3731269EF636F9D5B1EA180@CY4PR1601MB1254.namprd16.prod.outlook.com> <CY4PR1601MB1254B12910386A4EB149D35EEAF80@CY4PR1601MB1254.namprd16.prod.outlook.com> <BL0PR2101MB1027EC4E9CBA532DEF0099E8A3C90@BL0PR2101MB1027.namprd21.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BL0PR2101MB1027EC4E9CBA532DEF0099E8A3C90@BL0PR2101MB1027.namprd21.prod.outlook.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/UVWonaRyeTpyUw9ZKFRdnT2AURg>
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:40:44 -0000

[quoting is a bit busted, since color doesn't make it into text/plain]

On Wed, Apr 01, 2020 at 02:37:52AM +0000, Dave Thaler wrote:
>     
> 
>     
> 
>    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
>     
> 
>    5)  HTTP is susceptible to several attacks including pervasive monitoring,
>    any specific reason to support HTTP ?
> 
>     
> 
>    For debugging purposes before putting it into production.

It's not really clear to me that we need to include something in the
protocol spec that's just for debugging.  Do we really think people will
not figure out that they can use non-TLS HTTP for locally debugging an
HTTPS-based protocol?

>    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

(IMO the multiple layers do different things and complement each other, in
general.  I guess I haven't looked at this specific protocol in detail yet
but there's a general theme across protocols.)

-Ben