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

Carsten Bormann <cabo@tzi.org> Fri, 02 February 2018 13:09 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 DBEFA129BBF for <atlas@ietfa.amsl.com>; Fri, 2 Feb 2018 05:09:41 -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 4cqa_H-F480f for <atlas@ietfa.amsl.com>; Fri, 2 Feb 2018 05:09:40 -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 2FF9C127522 for <atlas@ietf.org>; Fri, 2 Feb 2018 05:09:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w12D9aSH028675; Fri, 2 Feb 2018 14:09:36 +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 3zXy4b32jHzDXT2; Fri, 2 Feb 2018 14:09:35 +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: <AM4PR0801MB2706FE84AD9FA00A183E07A7FAF90@AM4PR0801MB2706.eurprd08.prod.outlook.com>
Date: Fri, 02 Feb 2018 14:09:35 +0100
Cc: "atlas@ietf.org" <atlas@ietf.org>
X-Mao-Original-Outgoing-Id: 539269773.897516-09c7ceee0803f6b0aacd035696ec12f2
Content-Transfer-Encoding: quoted-printable
Message-Id: <A0EBC0E1-C63B-499F-ACF2-1EC2805A3A9E@tzi.org>
References: <AM4PR0801MB2706895905D2634096D4A11BFAEC0@AM4PR0801MB2706.eurprd08.prod.outlook.com> <548BB4CB-78F1-4CA8-92D6-E7174D8B1D8A@tzi.org> <AM4PR0801MB2706D8559615536F8F794F73FAF90@AM4PR0801MB2706.eurprd08.prod.outlook.com> <96D36092-5451-41AB-B441-5B93D6072561@tzi.org> <AM4PR0801MB2706FE84AD9FA00A183E07A7FAF90@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/teaNtB6MmzaF_xfGfSLREPPdkEM>
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 13:09:42 -0000

On Feb 2, 2018, at 13:34, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
> 
From: Carsten Bormann [mailto:cabo@tzi.org]
> 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 :-)
> 
> [Hannes] A fair concern. I have just have seen repeatedly how people mess up Bluetooth Smart security. Hence, I wonder whether a standardized approach in the IETF (which is the home of TLS) would make sense, or is at least worthwhile to try.

Sure, but I don’t think that kind of work can be done on the same timelines as the work on protocols we control and understand deeply.

When we did RFC 7668, we were pretty much done and then Bluetooth SIG essentially reversed half of the decisions and put that into Bluetooth, forcing us to follow suit.  The whole process took 4.5 years.

Grüße, Carsten