[Atlas] Review/discussion of ATLS related drafts

"Owen Friel (ofriel)" <ofriel@cisco.com> Thu, 20 September 2018 14:37 UTC

Return-Path: <ofriel@cisco.com>
X-Original-To: atlas@ietfa.amsl.com
Delivered-To: atlas@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F2154130EF4 for <atlas@ietfa.amsl.com>; Thu, 20 Sep 2018 07:37:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id X7D764g5jzD3 for <atlas@ietfa.amsl.com>; Thu, 20 Sep 2018 07:37:55 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F46130F25 for <atlas@ietf.org>; Thu, 20 Sep 2018 07:37:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31690; q=dns/txt; s=iport; t=1537454275; x=1538663875; h=from:to:subject:date:message-id:mime-version; bh=Znwbsg+XVK8C26OCEByJeRZYVnTRHbeGMyq+pDBRIe8=; b=b5K+1LVe2D931NlcozO+5ZKzGyBCO8TEv8TqKRp9uI5/u82cZG/gIHoc t11fHtoPoTLt7lLBZspZQe3+udNzVvZ4JzAzioWCBssem0Qxdb9B9BOKv cPAIq5DMc+DXmpQNpmPQxFwqtjZcDe8HY42696qeNfhIQMsxsCoSI4GnP 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAwCXr6Nb/4wNJK1bHAEBAQQBAQo?= =?us-ascii?q?BAYJhSAUqZX8ymC6Yb4FmC4gvITgUAQMBAQIBAQJtHQuFbF4BQAE/JgEEG4M?= =?us-ascii?q?agR1kpTOKF4ktgSUdF4FBP4ESgxKEQgkBEgGFdwKIOoUogUuNQQkCkBofjyK?= =?us-ascii?q?UTgIRFIElNCFkcXAVgyiCIwEXewECjRqMJoEfgR4BAQ?=
X-IronPort-AV: E=Sophos;i="5.53,398,1531785600"; d="scan'208,217";a="174573873"
Received: from alln-core-7.cisco.com ([]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2018 14:37:54 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com []) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id w8KEbsxH008009 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <atlas@ietf.org>; Thu, 20 Sep 2018 14:37:54 GMT
Received: from xch-rcd-012.cisco.com ( by XCH-ALN-012.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 20 Sep 2018 09:37:53 -0500
Received: from xch-rcd-012.cisco.com ([]) by XCH-RCD-012.cisco.com ([]) with mapi id 15.00.1395.000; Thu, 20 Sep 2018 09:37:53 -0500
From: "Owen Friel (ofriel)" <ofriel@cisco.com>
To: "atlas@ietf.org" <atlas@ietf.org>
Thread-Topic: Review/discussion of ATLS related drafts
Thread-Index: AdRQ74B+cS6QaaDtRhy9T3yNhbcSMA==
Date: Thu, 20 Sep 2018 14:37:53 +0000
Message-ID: <478f22e057d148109cd5916916397757@XCH-RCD-012.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_478f22e057d148109cd5916916397757XCHRCD012ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client:, xch-aln-012.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/atlas/RJu2Wt1P5JSVpj6NOqpc04SGc18>
Subject: [Atlas] Review/discussion of ATLS related drafts
X-BeenThere: atlas@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 20 Sep 2018 14:38:07 -0000


We never did get sufficiently organised to discuss this further in Montreal. Hopefully, this email will kick start some discussions that we can continue in Bangkok.

There have been quite a few different drafts, some current, some expired, mentioned on the mailers over the past year, and I've attempted to summarise the most relevant ones, and how they relate to ATLS, here:




Main Authors


ATLS Relevance





Ephemeral Diffie-Hellman Over COSE (EDHOC)
Defines an ECDH SIGMA based key exchange algorithm using COSE and COBR objects. It defines explicit parameter inputs to COSE and explicit signature, hash and encryption algorithms. Encryption is fixed as AES-CCM-64-64-128. Authentication is based on OOB provided PSK, RPK or Cert.

At a high level, trying to solve a similar problem: a key exchange algorithm that can be transported over any layer




Uni. Bremen

Requirements for CoAP End-To-End Security
Lists requirements for CoAP e2e security

Explicitly lists e2e application layer security as a key requirement, which is a key use case ATLS is trying to address.





Comparison of CoAP Security Protocols
Gives a header overhead byte count comparison of various encryption protocols (D/TLS 1.2/3, OSCORE).

Relevant as ATLS uses D/TLS protocol format. It would be worth noting that the overall data stream overhead of D/TLS headers is not as important if D/TLS is only used for key negotiation and key export and then OSCORE is used for encrypted data transport.





Object Security for Constrained RESTful Environments (OSCORE)
Uses COSE for COBR to protect CoAP messages e2e. It uses pre-shared keys that have been established OOB.

It does not cover key agreement, so ATLS for key agreement could be complementary to this.


(replaces draft-hartke-core-codtls)


Uni. Bremen

Practical Issues with DTLS in Constrained Environments
Outlines issues with fragmentation, packets loss, retransmissions etc. with DTLS in lossy constrained environments and gives a strawman for DTLS header compression.

While the highlighted issues are relevant for ATLS handshake packet transport over lossy networks, most of the issues have been addressed in other later drafts (e.g. DTLS1.3, RFC7925).




Uni. Bremen

CoDTLS: DTLS handshakes over CoAP
Defines how DTLS packets can be encoded into CoAP packets.

This is very relevant as there is an empty placeholder section in the ATLS draft on the encoding of D/TLS records over CoAP.




Uni. Murcia

Application Layer Security for CoAP using the (D)TLS Record Layer
Defines how CoAP messages and headers can be partially encrypted using keys that have been derived out of band. The bare minimum CoAP header info is left unencrypted to enable proxies to route packets, but not decrypt content.
It also touches on breaking apart handshake from encrypted data packet transport.

Similar, to OSCORE, it does not cover key agreement, so ATLS could be complementary to this. But the OSCORE draft, not this draft,  seems to be the preferred path forward.





Lightweight Establishment of Secure Session (LESS) on CoAP
Assuming that a PSK is exchanged OOB, it defines a new key agreement algorithm using some novel crypto that would need a thorough security review.
It also alludes to breaking apart handshake from encrypted data packet transport

At a high level, trying to solve a similar problem to both EDHOC and ATLS: it defines a key exchange algorithm.




ETH Zurich,

Separating Crypto Negotiation and Communication
Wants to explicitly break apart handshake packets from encrypted data packets so that handshake can happen in advance of packet transport. Acknowledges that there is no real benefit if encrypted data transport happens immediately after handshake.

We do mention using ATLS for handshake with key exporting, and encrypted data exchange happening out-of-scope of ATLS draft. Future TLS stack API optimisations could possibly be leveraged by ATLS to facilitate handshake vs. payload transport.

It appears as if the concepts from the ATLS draft combined with the CoDTLS work could be considered as viable alternatives to the EDHOC or LESS  proposals. There are advantages and disadvantages to both approaches which are worth discussing here. The ATLS approach has the advantage of not requiring definition of any new key negotiation protocol, we can use existing stacks as is, and piggy back on top of D/TLS1.3 protocol. Similar to EDHOC Appendix D, ATLS w/CoDTLS could be used as the key negotiation mechanism for OSCORE.

It would be great if we could have some discussions on the mailer prior to Bangkok, and see if there is any interest in having a side-meeting/lunch in Bangkok to discuss next steps and see if we can reach any consensus.