Re: [Cfrg] When TLS is an overkill...

kris@amongbytes.com Tue, 26 February 2019 09:06 UTC

Return-Path: <kris@amongbytes.com>
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 130DD130E9F for <cfrg@ietfa.amsl.com>; Tue, 26 Feb 2019 01:06:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Sf8KpzxzDGBr for <cfrg@ietfa.amsl.com>; Tue, 26 Feb 2019 01:06:43 -0800 (PST)
Received: from 1.mo7.mail-out.ovh.net (1.mo7.mail-out.ovh.net [178.33.45.51]) (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 AF9CE130E9E for <cfrg@irtf.org>; Tue, 26 Feb 2019 01:06:43 -0800 (PST)
Received: from player695.ha.ovh.net (unknown [10.109.146.143]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id 0195E102E56 for <cfrg@irtf.org>; Tue, 26 Feb 2019 10:06:40 +0100 (CET)
Received: from amongbytes.com (94.197.120.96.threembb.co.uk [94.197.120.96]) (Authenticated sender: postmaster@amongbytes.com) by player695.ha.ovh.net (Postfix) with ESMTPSA id 0B9462F8DD6C; Tue, 26 Feb 2019 09:06:37 +0000 (UTC)
Date: Tue, 26 Feb 2019 09:06:35 +0000
User-Agent: K-9 Mail for Android
In-Reply-To: <b1fae97c-da97-9745-55cc-d396abe906a0@gmail.com>
References: <307807bf-09eb-96c7-028f-df9573463b11@openca.org> <1551140056245.65505@cs.auckland.ac.nz> <d53dd35f-dcb0-a562-d432-955dc30155b3@openca.org> <b1fae97c-da97-9745-55cc-d396abe906a0@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----Z7O8YDE9VULFQ2CPIHI840O51IWACO"
Content-Transfer-Encoding: 7bit
To: cfrg@irtf.org, Ruslan Kiyanchuk <ruslan.kiyanchuk@gmail.com>, "Dr. Pala" <director@openca.org>
From: kris@amongbytes.com
Message-ID: <FFD5A834-9C68-4F70-BD3F-371F820891D4@amongbytes.com>
X-Ovh-Tracer-Id: 117093593486638925
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrudelgddtudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/v-Uu63M5pz9p9gwhWHlJi-UsFDU>
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 09:06:46 -0000

Sounds like goal is quite similar to what noise protocol framework tries to achieve. 

On 26 February 2019 08:45:45 GMT, Ruslan Kiyanchuk <ruslan.kiyanchuk@gmail.com> wrote:
>> 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
>>
>I think you might be trying to reinvent Noise protocol framework
><http://www.noiseprotocol.org/> :)
>
>It's a framework designed to be simple and straightforward for for
>securing 2-party communication. By combining different elements of the
>protocol you achieve various security properties. There is also a third
>party website Noise Explorer <https://noiseexplorer.com/> where you can
>explore various settings of the framework and corresponding security
>properties.
>
>By your description so far it sounded like a good fit.
>
>Another mention that may be relevant is Google's ATLS
><https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security/>
>(it's their home-grown TLS alternative, I'm not aware how much scrutiny
>and analysis it underwent).
>
>Good luck!