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