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