IETF Logo Mail Archive

Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Carsten Bormann <cabo@tzi.org> Fri, 02 February 2018 12:11 UTC

Return-Path: <cabo@tzi.org>
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 275D412426E for <atlas@ietfa.amsl.com>; Fri, 2 Feb 2018 04:11:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 fiw1ZFHUoawd for <atlas@ietfa.amsl.com>; Fri, 2 Feb 2018 04:11:42 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 C810D129C6B for <atlas@ietf.org>; Fri, 2 Feb 2018 04:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w12CBbqm010798; Fri, 2 Feb 2018 13:11:37 +0100 (CET)
Received: from sev.informatik.uni-bremen.de (sev.informatik.uni-bremen.de [134.102.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zXwnj4WgnzDXSC; Fri, 2 Feb 2018 13:11:37 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <AM4PR0801MB2706D8559615536F8F794F73FAF90@AM4PR0801MB2706.eurprd08.prod.outlook.com>
Date: Fri, 02 Feb 2018 13:11:37 +0100
Cc: "atlas@ietf.org" <atlas@ietf.org>
X-Mao-Original-Outgoing-Id: 539266296.314049-3bf84adbf32db6d6f11bc826e7a57190
Content-Transfer-Encoding: quoted-printable
Message-Id: <96D36092-5451-41AB-B441-5B93D6072561@tzi.org>
References: <AM4PR0801MB2706895905D2634096D4A11BFAEC0@AM4PR0801MB2706.eurprd08.prod.outlook.com> <548BB4CB-78F1-4CA8-92D6-E7174D8B1D8A@tzi.org> <AM4PR0801MB2706D8559615536F8F794F73FAF90@AM4PR0801MB2706.eurprd08.prod.outlook.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/atlas/D5lt7WiWFY4UYlvTj4SoJQpvnbY>
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text
X-BeenThere: atlas@ietf.org
X-Mailman-Version: 2.1.22
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, 02 Feb 2018 12:11:44 -0000

On Feb 2, 2018, at 12:53, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
> 
> embeddings for different application protocols, such as CoAP, HTTP, and Bluetooth Smart

Hannes,

I’d sure like to complete CoDTLS, so that looks much better for me now.
I would expect we can define media types that work for both CoAP and HTTP, so that integration should probably be left open as something for the WG to decide.

Not so sure about “Bluetooth Smart” — are we optimistic with respect to attracting enough people that at least know that this is no longer the name of Bluetooth Low Energy :-)

I’m also not so sure about the Architecture and Use Case document as a separate item; we could simple add a page or two to the introduction of the media types document.

Finally, I’ll have to add the ceterum censeo that I don’t think the complex TLS should have a monopoly on key agreement protocols, and that I think we should also complete EDHOC.

Do we have a position on TLS/DTLS 1.3?  Or is that for the WG to decide?

Grüße, Carsten

v2.23.0 | Report a Bug | By Email