Re: [Cfrg] When TLS is an overkill...
"Dr. Pala" <director@openca.org> Tue, 26 February 2019 01:25 UTC
Return-Path: <director@openca.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7680A130E2B for <cfrg@ietfa.amsl.com>; Mon, 25 Feb 2019 17:25:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 Uukbs3K5g4Sn for <cfrg@ietfa.amsl.com>; Mon, 25 Feb 2019 17:25:40 -0800 (PST)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id C232412E7C1 for <cfrg@irtf.org>; Mon, 25 Feb 2019 17:25:39 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 684703741015; Tue, 26 Feb 2019 01:25:39 +0000 (UTC)
X-Virus-Scanned: amavisd-new at katezarealty.com
Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BAqYJZ8epytL; Mon, 25 Feb 2019 20:25:38 -0500 (EST)
Received: from CableLabsMacWork.hsd1.co.comcast.net (c-73-203-120-205.hsd1.co.comcast.net [73.203.120.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 4FD4737407FD; Mon, 25 Feb 2019 20:25:38 -0500 (EST)
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "cfrg@irtf.org" <cfrg@irtf.org>
References: <307807bf-09eb-96c7-028f-df9573463b11@openca.org> <1551140056245.65505@cs.auckland.ac.nz>
From: "Dr. Pala" <director@openca.org>
Organization: OpenCA Labs
Message-ID: <d53dd35f-dcb0-a562-d432-955dc30155b3@openca.org>
Date: Mon, 25 Feb 2019 18:25:37 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <1551140056245.65505@cs.auckland.ac.nz>
Content-Type: multipart/alternative; boundary="------------BAB4693E8A72F2705C21173E"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/RtxmnB3KfaZnEnb7Bx355I3mIC0>
Subject: Re: [Cfrg] When TLS is an overkill...
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Feb 2019 01:25:48 -0000
Hi Peter, responses and comments inline... On 2/25/19 5:14 PM, Peter Gutmann wrote: > Dr. Pala <director@openca.org> > >> I noticed that sometimes people use TLS to establish a secure channel with a >> server even when all they want to do (i.e., no extra features/checks/etc.) >> could potentially be achieved in just 2/3 messages. An example of this is EAP >> - whenever a secure channel needs to be established, EAP-TLS, EAP-TTLS, EAP- >> TEAP, etc. must be supported to tunnel the 2nd method that will be used for >> authentication. > That's because it's required for EAP, which in the form of EAP / RADIUS is the > universal standard for device authentication. There are (at least) tens of > billions of devices that use this somewhere. It's not used because it's a > technically good solution (running EAP over DIAMETER over EAP-TLS over EAP > over RADIUS over UDP is probably close to insane), but because there's a vast > global infrastructure that supports it. Yes, I always found the stacking of protocols for EAP insane... but it must not be too insane if we deployed such a large support for it. Just the right amount of insanity, I guess :D I tried to launch the idea that maybe we can re-visit EAP... but that was simply a no-go :D [ Updating standards seems like its becoming sooo difficult - there are always people that knock ideas down just because... thus keeping us in the dark ages for no good reason other than their companies might make more money with inefficient systems - look at the status of PKIs - we need to stop sayin "no" all the time and work for a better Internet ] >> My question for the group is: if we were to use a "simple" way to establish >> the secure channel, are there recommendations for what should be in those >> messages ? What would be the minimum set of required data that MUST be >> included in the exchange ? > Also, what colour should the various pieces be painted, and should it be > gloss, satin, or matt? > > You're asking the wrong question(s). What problem are you trying to solve? > Without that frame of reference, it's not possible to answer any of the > questions you're asking. > > If you want an example of some designs that do a good job of solving a > particular problem, look at LoRaWAN security or WireGuard. They solve a > specific, widely-encountered problem, and they do a pretty good job of it > without adding a ton of unnecessary bloat. What I am trying to do is quite simple: /provide a building block that developers and engineers can use to secure the communication between two peers by using a low number of messages/. In particular, I think that this building block could help many developers to do the right thing when not using TLS. Do not get me wrong, TLS is great.. however, it might be useful to have an alternative. My particular use case (but this is just one, there might be many others) is specifically EAP. In EAP, it seems, people always try to re-use deployment even when they do not make much sense (e.g., insane protocol stack) - i.e., always trying to fit a square peg in a round hole, so to speak. Can we do better ? Instead of using the square peg (TLS) with the round hole (to create a security association and optionally authenticate), can we provide a (BCP ?) document that provides the reader with the minimum viable messages for securing the communication ? The main difference with TLS would be (a) no session resumption/tickets/etc., (b) not direct connection is required (transport independent - message based), (c) no support for TLS "extensions", (d) remove the dns validation from the equation (i.e., the network location of the server does not matter since it can not be verified - see (b)). A building block like that could be used in many different environments and over many different transport protocols - from this point of view, if we do something, lets' make it useful for everybody and applicable in many different environments (i.e., encoding-independent with specific conversion rules, maybe ?) and settings (not just for my specific use-case EAP). Does this answer your question ? And my original question still stand - is there an RFC already out there that can be used for this ? Or that can be used as a starting point for this ? Thanks again for the comments and questions :D Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo
- [Cfrg] When TLS is an overkill... Dr. Pala
- Re: [Cfrg] When TLS is an overkill... Adam Langley
- Re: [Cfrg] When TLS is an overkill... Stanislav V. Smyshlyaev
- Re: [Cfrg] When TLS is an overkill... Dr. Pala
- Re: [Cfrg] When TLS is an overkill... Carsten Bormann
- Re: [Cfrg] When TLS is an overkill... Peter Gutmann
- Re: [Cfrg] When TLS is an overkill... Dr. Pala
- Re: [Cfrg] When TLS is an overkill... Peter Gutmann
- Re: [Cfrg] When TLS is an overkill... Ruslan Kiyanchuk
- Re: [Cfrg] When TLS is an overkill... kris
- [Cfrg] Higncryption and CNKE might be useful Re: … 赵运磊
- Re: [Cfrg] When TLS is an overkill... John Mattsson