Re: [EAT] [Rats] Rats and EAT

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Sun, 15 July 2018 21:14 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 38647130E88; Sun, 15 Jul 2018 14:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 TcMquzZUlUpU; Sun, 15 Jul 2018 14:14:04 -0700 (PDT)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 EEAF3130E69; Sun, 15 Jul 2018 14:14:02 -0700 (PDT)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w6FLDxQB017108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 15 Jul 2018 23:14:00 +0200
Received: from [31.133.150.210] (31.133.150.210) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.399.0; Sun, 15 Jul 2018 23:13:54 +0200
To: Yaron Sheffer <yaronf.ietf@gmail.com>, Laurence Lundblade <lgl@island-resort.com>, Michael Richardson <mcr+ietf@sandelman.ca>
CC: "rats@ietf.org" <rats@ietf.org>, "eat@ietf.org" <eat@ietf.org>
References: <eb1d952b-1e73-4c41-bf12-82299b44ff3d@me.com> <0FE06C34-D430-451C-834B-0A39082160BA@island-resort.com> <32302.1531356373@localhost> <678D5903-580B-4AD7-87D9-5A779A005194@island-resort.com> <e55daa1f-1158-d226-f35a-0244ea4a1016@gmail.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <dd8bda86-42c4-2778-2dca-a4c43a824b2d@sit.fraunhofer.de>
Date: Sun, 15 Jul 2018 17:13:51 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <e55daa1f-1158-d226-f35a-0244ea4a1016@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [31.133.150.210]
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/alML8fJpi72mcba9uRPK7D7OmPc>
Subject: Re: [EAT] [Rats] Rats and EAT
X-BeenThere: eat@ietf.org
X-Mailman-Version: 2.1.27
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: Sun, 15 Jul 2018 21:14:07 -0000

Hi all,

sometimes - and this might be a purely subjective perception - the fact 
that "concise" or IoT target solutions "seem" to violate a very curious 
requirement poses - please mind - a somehow surprising strong "impact":

The encoding data in motion is not (directly) human readable.

Wrt to Yaron's comment: this assumption should not be a valid reason for 
not to apply concise & scalable technologies in other scopes (aka bigger 
things) than constrained-nodes environments.

Maybe there are very valid reasons not to apply IoT solutions to "bigger 
things" domains - and that would be very important to understand better 
- but taking into account the t2t philosophy, I am hopeful that there is 
no actual reason not to aspire to that.

Viele Grüße,

Henk



On 07/15/2018 08:50 AM, Yaron Sheffer wrote:
> On 12/07/18 19:20, Laurence Lundblade wrote:
>> On Jul 11, 2018, at 5:46 PM, Michael Richardson 
>> <mcr+ietf@sandelman.ca> wrote:
>>>
>>> Laurence Lundblade <lgl@island-resort.com> wrote:
>>>> NEA is oriented around network management, trying to track the security
>>>> posture of devices in an enterprise's network. EAT is broadly targeted
>>>> at establishing trust between entities, often consumer devices (phones,
>>>> refrigerators, cars...) and servers/services (online banking, IoT
>>>> services, enterprise authentication…).
>>> That's a surprising claim that EAT is going to broker trust between 
>>> my phone
>>> and my refrigerator.    Will it do this via third parties, or directly?
>> This is not any direct goal of EAT. Let me say it better:
>>
>> EAT is broadly targeted at providing some basis for establishing trust 
>> in scenarios like this:
>>   - An online banking website trusting the phone and app used to show 
>> account balance
>>   - A Fortune 500 corp trusting the phone and web browser to allow 
>> access to corp data
>>   - An IoT backend trusting some refrigerators that it is to provide 
>> service to (e.g. shopping, milk expiration…)
>>
>> Maybe someday EAT will be part of a phone-fridge trust solution, but 
>> one step at a time.
>>
> I don't see how in this day and age we can consider a solution that 
> covers IOT and phones but not other devices that run an operating 
> system, such as laptops and servers.
> 
> So maybe NEA was too complex or ambitious, and we should scale these 
> ambitions down. But desktops and servers, both physical and virtual, 
> should be in scope.
> 
> Thanks,
>      Yaron
> 
> _______________________________________________
> EAT mailing list
> EAT@ietf.org
> https://www.ietf.org/mailman/listinfo/eat