Re: [Atlas] Review/discussion of ATLS related drafts
Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com> Sun, 21 October 2018 12:48 UTC
Return-Path: <prvs=825137a0c=abhijan.bhattacharyya@tcs.com>
X-Original-To: atlas@ietfa.amsl.com
Delivered-To: atlas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2A7130FAB; Sun, 21 Oct 2018 05:48:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tcs.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 RcyMaZpJxJrq; Sun, 21 Oct 2018 05:48:49 -0700 (PDT)
Received: from indelg02.tcs.com (indelg02.tcs.com [203.200.109.58]) (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 9715D12DD85; Sun, 21 Oct 2018 05:48:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcs.com; i=@tcs.com; q=dns/txt; s=default2048; t=1540126128; x=1571662128; h=in-reply-to:references:to:cc:mime-version:subject: message-id:from:date; bh=AHJ1W7aozPgYMl6wX0ASO7LuRJ0jSy5XRpkuzkRucsM=; b=fJ2Q1Z5DNpF1pkfywUt6rxxrsblylu74qPnC90QtZUmQnIQondShMsQ1 ihDzXPZSJqpa3bsETHhqmSagiL+E9EiYaOaxej3+ldi0llZeC6F+m2fcu qnPBrwO40e9iO33ApgkPmfJjbNCHCwWJelZG1/pQuNuFCtE0PacMjxAXg 1+y8tpFWHR4rCsOx7pCCN2gx32SYAsPrhPrskQLU+2evnzLXdA2Q6X5CJ BgJfQg/i2R2dRv0PhqTvCDV19jv+0Zs+OKDiPlRG5PibhFY3iSpnqIp2y V5ZnKxGdLuwPr9yIVsnPuwroOlacJpGws44S4MFrwLAL8IPZSaT33jZrX g==;
IronPort-PHdr: 9a23:pvTvIxTxLAb+06CVTw8HioylNtpsv+yvbD5Q0YIujvd0So/mwa6zbBGN2/xhgRfzUJnB7Loc0qyK6/+mATRIyK3CmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+KPjrFY7OlcS30P2594HObwlSizexfbF/IA+qoQnNq8IbnZZsJqEtxxXTv3BGYf5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM30u683wqRbDVwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xymp4qF2QxHqlSgHLSY0/2PZisJug61VvRWvqR9/zYDafI6YL+Bxcr/HcN4AX2dNQsRcWipcCY28dYsPCO8BMP5Eoobmp1sOrBm+ChOqBOjy1zJIhmX53bEm0+s7DQ7G3BYvH8gOsXXUttr+KaAfXvquw6nIzDXDbelZ2THn5IfTchAuu+2MXa5qfsXNyUkgDRnFj1WQqIP/JD6VyvgCs3OB4+V8UuKvjncqpgdsqTahwccsj5PGhoMTyl3c9CV23po1JdOiRE58e96kH4Nctz2GOIttWM8tX2ZouCM8x7YbupC7ZDAHxIklyhLBcfCLbouF7gj9WOufOzt1i3Roc6+liRmo60iv0Oj8W9Gx0FZNsyVKjMHBtmsI1xzP8siHTeZ9/lu51TaPyQ/T7uZELFg3m6TDLpAv27g+mIcPvErFECH4nl/4gqiIeEg45+Sk8+XnYrP4qZ+AL4J4lwPzPro0lsCiAuk0KBYCUmaB9emzzLHj+Ff2QLROjv04iKnZt5XaKNwBqaGiAw9V04Qj5Ay5Dzu8y9sYnWMILE5ZeB2dk4fpO0vBIOr4DPa/mVuhiytryOzdPrH7HprNKX3DnK/7fblh805c1BYzzddH6pJTBLEBOvPzVVH1tNHAARI1LxC7w+f8CNph0YMSQ36AAqicMK7JrFCI4/ggI/OQa4MPuTbyNeQl5/D0gX8+g18dcrGj3YELZ3CgAvRmP0KZbGL2jdcdFWcFpBE+QPXxh12FTD5TYWq9ULwn5jwgCYKpE5vDRo63jLyGxie7EYVcZnpaBVCUDXfoa4KEVu8WZyKOJs9uiCcEWKOgS4A/yRGuuhX2y719LurbqWUkssep88d44aX9jxA/8XRAT8OTyWCAS1U11CtcQDEs3a179BAlwVaY2q8+iPtdPdBW7ulCFAY3KZCayPZ1XYPcQAXEK/6DSFekS9PuKzE4Us44yN8HeVdsEp32hxrD3iijBfkfl7WXGJU/8qvGzmn4D9p20DDN06x33ApueddGKWDz3v03zAPUHYOcy0g=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2A+AAAYdcxb/wQXEqxkHgEGBwaBUQkLAYFVBYEQgSeDdZY9lxUUgWYlAQqESQIXhRI0DQ0BAwEBAgEBAgGBCAyCNiKCYgEBAQEDAQEhSwsQCwcGBAMBAiEHAwICAiUfCQgGCwgbgwYBghCjKQEBAW2BLoU8hFaKEIElP3d+gRGCFH6DGwEBAoEjCQESATYIARaCTS2CKgKIYhCGS0+EO4oBBwKCD456kC6YIIEccXBQgmwJghwBF30BAoJIhRSFRmcBiHmCPgEB
X-IPAS-Result: A2A+AAAYdcxb/wQXEqxkHgEGBwaBUQkLAYFVBYEQgSeDdZY9lxUUgWYlAQqESQIXhRI0DQ0BAwEBAgEBAgGBCAyCNiKCYgEBAQEDAQEhSwsQCwcGBAMBAiEHAwICAiUfCQgGCwgbgwYBghCjKQEBAW2BLoU8hFaKEIElP3d+gRGCFH6DGwEBAoEjCQESATYIARaCTS2CKgKIYhCGS0+EO4oBBwKCD456kC6YIIEccXBQgmwJghwBF30BAoJIhRSFRmcBiHmCPgEB
X-IronPort-AV: E=Sophos;i="5.54,408,1534789800"; d="scan'208";a="21650444"
In-Reply-To: <478f22e057d148109cd5916916397757@XCH-RCD-012.cisco.com>
References: <478f22e057d148109cd5916916397757@XCH-RCD-012.cisco.com>
To: "Owen Friel (ofriel)" <ofriel=40cisco.com@dmarc.ietf.org>
Cc: "atlas@ietf.org" <atlas@ietf.org>, Atlas <atlas-bounces@ietf.org>
MIME-Version: 1.0
X-KeepSent: 8FC5E3C3:654AC775-6525832D:004619B1; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0 March 08, 2013
Message-ID: <OF8FC5E3C3.654AC775-ON6525832D.004619B1-6525832D.00465EED@tcs.com>
From: Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>
Date: Sun, 21 Oct 2018 18:18:37 +0530
X-MIMETrack: Serialize by Router on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 10/21/2018 18:18:39, Serialize complete at 10/21/2018 18:18:39
Content-Type: multipart/alternative; boundary="=_alternative 00465EEC6525832D_="
Archived-At: <https://mailarchive.ietf.org/arch/msg/atlas/6WKJs5GvxIF5b1MI-NINfUsiSNY>
Subject: Re: [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: Sun, 21 Oct 2018 12:48:52 -0000
Hi Owen, It is an excellent summary. I hope to be present in Bangkok IETF. Would like to participate in any related discussion in any possible form. Thank you. With Best Regards Abhijan Bhattacharyya Consultant / Scientist, {Internet Protocols | 5G | Standardization}, TCS Research, Tata Consultancy Services Building 1B,Ecospace Plot - IIF/12 ,New Town, Rajarhat, Kolkata - 700160,West Bengal India Ph:- +91 33 66884691 Cell:- +919830468972 | +918583875003 Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ From: "Owen Friel \(ofriel\)" <ofriel=40cisco.com@dmarc.ietf.org> To: "atlas@ietf.org" <atlas@ietf.org> Date: 09/20/2018 08:09 PM Subject: [Atlas] Review/discussion of ATLS related drafts Sent by: "Atlas" <atlas-bounces@ietf.org> "External email. Open with Caution" Folks, 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: # draft Expires Main Authors Summary ATLS Relevance 1 draft-selander-ace-cose-ecdhe 01-19 Ericsson 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 2 draft-hartke-core-e2e-security-reqs 01-18 Ericsson, 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. 3 draft-ietf-lwig-security-protocol-comparison (replaces draft-mattsson-core-security-overhead) 01-19 Ericsson 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. 4 draft-ietf-core-object-security 12-18 Ericsson 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. 5 draft-hartke-dice-practical-issues (replaces draft-hartke-core-codtls) 10-14 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). 6 draft-schmertmann-dice-codtls 02-15 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. 7 draft-garcia-core-app-layer-sec-with-dtls-record 06-17 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. 8 draft-bhattacharyya-dice-less-on-coap 09-18 TATA 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. 9 draft-kuehlewind-taps-crypto-sep 01-19 ETH Zurich, Apple 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. Cheers, Owen_______________________________________________ Atlas mailing list Atlas@ietf.org https://www.ietf.org/mailman/listinfo/atlas =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
- [Atlas] Review/discussion of ATLS related drafts Owen Friel (ofriel)
- Re: [Atlas] Review/discussion of ATLS related dra… Abhijan Bhattacharyya