[Atlas] Status Update

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Fri, 08 June 2018 11:44 UTC

From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: "atlas@ietf.org" <atlas@ietf.org>
Thread-Topic: Status Update
Thread-Index: AdP/HdU64ZzegsYNSRueEze+jifg2g==
Date: Fri, 08 Jun 2018 11:44:07 +0000
Message-ID: <VI1PR0801MB2112385E74223CC722B0E2A1FA7B0@VI1PR0801MB2112.eurprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112385E74223CC722B0E2A1FA7B0VI1PR0801MB2112_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 40b7d170-a150-4753-d853-08d5cd35247c
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2018 11:44:07.0964 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2064
Archived-At: <https://mailarchive.ietf.org/arch/msg/atlas/SXm82pk2GOqAvw0y_q-YVRkQSTA>
Subject: [Atlas] Status Update
X-BeenThere: atlas@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Application Transport LAyer Security <atlas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/atlas>, <mailto:atlas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/atlas/>
List-Post: <mailto:atlas@ietf.org>
List-Help: <mailto:atlas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/atlas>, <mailto:atlas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jun 2018 11:44:15 -0000

Hi all,

Owen and I submitted another BoF proposal to the IESG based on the feedback from the last IETF meeting.

Here is the most recent charter text we came up with:
---
There are multiple scenarios where clients and servers need to negotiate shared encryption keys and establish secure, authenticated, integrity-protected, end-to-end encrypted sessions at the application layer over untrusted transport. There are a proliferation of transport protocols and mechanisms in use today across web and IoT use cases including, but not limited to, TCP, UDP, IP, Bluetooth and Zigbee. Additionally, network topologies often include middleboxes and proxies that terminate transport layer connections from clients and re-originate new transport layer connections towards the servers. From the clients and servers perspective, these transport layer proxy functions are untrusted and application data must be protected and encrypted, and not exposed to these proxies. There are multiple potential mechanisms that could be considered for negotiation of encryption keys, and establishment of end-to-end encrypted sessions at the application layer between clients and servers, and this working group proposes use of existing (D)TLS protocols and stacks.

This working group proposes reuse of (D)TLS at the application layer as a simple and straightforward means of achieving the security and implementation goals. The primary purpose of the working group is to develop specifications defining how (D)TLS can be leveraged at the application layer (i.e. Application Layer TLS or ATLS) to establish end-to-end encrypted sessions over a multitude of different transports.

Additionally, during development of ATLS specifications, the working group will consider and address concerns such as:

o complex, multi-hop and lossy transport topologies
o (D)TLS record fragmentation at the transport layer
o middlebox operators whose goals include interception of application layer data

The working group will engage with other relevant working groups across the Applications and Real-Time Area (art), Security Area (sec) and Transport Area (tsv), and one of the goals of this working group is to explicitly identity all related working groups that must be consulted during ATLS specifications development.
---

There do not seem to be minutes available from the IESG/IAB BoF discussions and how they reached their conclusions. So, we can only report what has been told to us by proxy.

In any case, the IESG rejected the BoF proposal.

The impression from the IESG was that the Bar BOF in London produced mixed feelings and that there was no activity on the list afterwards.
Another comment was that the required standardization effort is too small to justify the setup of an entire working group.

At first, this sounds a bit negative. On the other hand, we have two implementations right now. While they need to be polished I believe this is something we could go forward with.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: [Atlas] Status Update Hannes Tschofenig
Re: [Atlas] Status Update Hannes Tschofenig
Re: [Atlas] Status Update Benjamin Kaduk
Re: [Atlas] Status Update Mirja Kühlewind
Re: [Atlas] Status Update Abhijan Bhattacharyya
Re: [Atlas] Status Update Hannes Tschofenig
Re: [Atlas] Status Update Mirja Kühlewind
Re: [Atlas] Status Update Mirja Kühlewind
Re: [Atlas] Status Update Abhijan Bhattacharyya
Re: [Atlas] Status Update DAN GARCIA CARRILLO
Re: [Atlas] Status Update Martin Thomson
[Atlas] Status Update Hannes Tschofenig
Re: [Atlas] Status Update Russ Housley
Re: [Atlas] Status Update Dan García Carrillo
Re: [Atlas] Status Update Abhijan Bhattacharyya
Re: [Atlas] Status Update Abhijan Bhattacharyya