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

Ruslan Kiyanchuk <ruslan.kiyanchuk@gmail.com> Tue, 26 February 2019 08:46 UTC

Return-Path: <ruslan.kiyanchuk@gmail.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 0AFF71228B7 for <cfrg@ietfa.amsl.com>; Tue, 26 Feb 2019 00:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 PHll44q7n5Qz for <cfrg@ietfa.amsl.com>; Tue, 26 Feb 2019 00:46:01 -0800 (PST)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5BDB130E95 for <cfrg@irtf.org>; Tue, 26 Feb 2019 00:46:00 -0800 (PST)
Received: by mail-pf1-x42f.google.com with SMTP id n125so5904322pfn.5 for <cfrg@irtf.org>; Tue, 26 Feb 2019 00:46:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:autocrypt:cc:message-id:date :user-agent:mime-version:in-reply-to; bh=qFlVnrLGf6D4xgnWOB777aHUlMfV5S6Z2ED6OLNVFMI=; b=tOQiAKULbqIgyfu7CGZ6VX91O0F2zwjecjxsvFB862Um36CG/NKLQ+kJ2ybUBDEQaL i9NTbs2iMmFICivYQ1H/QX2TZ7jYYCb6KotBNRNf4jjZ3Pi+rH1hq4IG7ri+5Em4FdWa FGseCvX/TnBau5MlyIcR7nYpdTEe/tslQkaAfVtqXWwR4GJaHxSdFn/rRMYZ/r269yFz zDw5R22rRmcPvmrNl0hzoZD4cPkt8M39/Jv4zwSuIhsYVTNcKCim71iTd1RAp8G8Rcde oKmAuqgGzfJXF79+0E8YtgLcmTahZjJQxm+ss1V0KPt1EkAF/F0KKkOkKHd3uxTpIvQX 3qTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt:cc :message-id:date:user-agent:mime-version:in-reply-to; bh=qFlVnrLGf6D4xgnWOB777aHUlMfV5S6Z2ED6OLNVFMI=; b=E3iJ7FkvLLc40m030KGFhgLgBq4xYKVtgrctTS5PLe18PRS9R+KJqqERc8o86ngIQs YxbZ5b6tGqZ5pWySh7jWvqF67zrWIwofZzDHFC3dQVo07aK/GwWK6xlx5cDePQVS9Fna yC95/DSwIgZIazuJKdUS/zJo2regU2Ap7AcZoNDrRVkqOwli8AV+M2NSKBJawjPJHGBn 3YSY5MkM8t7L4iU5bldW3Chqu8Za1ig8jYal3s1ion6Oc9MQu6JFz70+aj0gDJb+2T+X jo7h3gd9K97MyJOyZI8Mv3ZW6wnoNtn1OzsD7Wn6sFz2smvtFA9ZqUTkAjS5dEdBANbF O8WA==
X-Gm-Message-State: AHQUAubO3zryTK1oeHUMiazL3EnNQOMRODUg9MbZCScLPbikMOivTaAf MfyFmbWagDdIoM85t6Drc8Ro3Tba
X-Google-Smtp-Source: AHgI3IZERutuD9vy4Ri+WYw0ktgRPqdXSKpKxwlcqcwgmazKGp09xBjLeCAYWCMFzcG23uY0TjZEPw==
X-Received: by 2002:a62:ea0f:: with SMTP id t15mr1242692pfh.124.1551170759977; Tue, 26 Feb 2019 00:45:59 -0800 (PST)
Received: from [192.168.1.196] (c-24-130-65-46.hsd1.ca.comcast.net. [24.130.65.46]) by smtp.gmail.com with ESMTPSA id i186sm26298828pfc.28.2019.02.26.00.45.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 00:45:59 -0800 (PST)
To: "Dr. Pala" <director@openca.org>
References: <307807bf-09eb-96c7-028f-df9573463b11@openca.org> <1551140056245.65505@cs.auckland.ac.nz> <d53dd35f-dcb0-a562-d432-955dc30155b3@openca.org>
From: Ruslan Kiyanchuk <ruslan.kiyanchuk@gmail.com>
Openpgp: preference=signencrypt
Autocrypt: addr=ruslan.kiyanchuk@gmail.com; keydata= mQINBFuu/kwBEADCIf2WYyijyvwSjxTkJgxylFss1w0rGbcEDpFlOIvccu+3ek/kC6V8Vrvt NWMwdSNDfwtSKQjD2e8fCxFBM5QnId3DZas2cqLD8umI2QmelzdAxtSh9PNHNsIiTemOtLYJ MslqJFIAI90qKMtVr7J/O1gXkQ9lCDNQSnBPaQ2fnDRC/6Sw2sETnnXvmvSvmcYip5K0np6F JJKEprXeIh9dAmALGzwXLYnL+kIkdHMgtgQ97hfKKhFQACQ3cPJIDNUOk63I8Lb8Cg+fyv7I xG/TljbEs7Gmasu2MhJaGqYxGLx6iBQ4Yy2RMcpzzYRuzaxelJs24mBcODnManNIv3cGUR7a ZG0nH52p5eKK3KC0sIkF3YBiNM0oG6ZG6Ys5nhedgpznS6sUxGmLI2OlQIJ5LYKgY1/Zz3pj 2VukyKMwjOuPcJNPDRW2l8htWoAIQ7P7R0cCck9sBY3W9BjQeKBdP4vsWaKjLdD1R6cgRInG ANX0MzBuAy6lz0EZDi5G5opn7II/qfuX7Kf3VBN38Tfr8L/xh252IF1g3TftnxEpol5E3Uxp B6axD0mIVKz1Sl/F1DsbtK0scWZDq2F8TGMK4SxirS0Y5xBmk+uOgmXqpy0ZyQ+UyoJB1iV1 41mCGlBop3Frjm/2A4lsKRjAyi5seHH/YDOLntPbKwMbKTT3fwARAQABtC1SdXNsYW4gS2l5 YW5jaHVrIDxydXNsYW4ua2l5YW5jaHVrQGdtYWlsLmNvbT6JAlkEEwEKAEMCGwMHCwkNCAoH AwUVCgkICwUWAgMBAAIeAQIXgAIZARYhBKSMT9au7hn2HQ7Dtfr8vorZzRz5BQJcMSeRBQkC Y1zFAAoJEPr8vorZzRz5MSIP/jJSU7YD7AmSWrsg4XdvnkRjOCk/fMVypmaMjB3MwXNp5fQ3 x7+lCiAWlkEv+f6+wgdFHxCq8DiDA0Sn6NABF4M2IoXPS09YbdEkL5fbfb2pCEdbBg+cY7gl JPXFv9fKeW+HrytGURXG5UWbL4ur85gwBji8uWmdEJPfoTI0OZi9LhTbZTeuO4811IxNlJtf adHLkzxfM7JkfOACEcVhXZPYORpl0TAPBKIUwZxJmfbsV9In/SeOp/zEnF5Mp07iMuDRJVX0 zrjz/JfedRTkPFvqZ4OxxOfpGGIQve2goI2RZ7fl0XjNs4EW6F5yYQB1o6s3B7ybHj1WXXuF 2XM+k9uxR8c63ppWo/62utqOrOe7XVB7QShkcBMbBnx2FJu1qBfOAU6o7Yfud94UusppQJq3 UH0FYQTKJd6e/J2xeamn+rT03ZJv1f0V/Hn3hHwdtnLautsYDRrnmByAwRQkL7OZy/T4/Ase qyjwSu7Pi6xyFEgGPfwNtfLSyvEnQJupg2iMB0jFhpwFos5zHnm18nn3bRno07DuhV6+zwBz 0XGj+bNE+oKVv84Zjwx7pTIh6/lYAi3gtyZJSpJwUyfOYxioXz6JaSBQ1s1XnZGHWR0NcSQt x5+SaAZFdTNE5v2G8MlnmOTUpwVwNShwT0JEFTXdrw/dNL4AZoywMkc349PsuQINBFuu/kwB EACvw5kf9EjKxzBYW98D82o5gmEK4IKlKlEpT5FzZQpNPhyFWkWCJ3NUsZ9UnNkMhU429EbW +m4zIU2eou8UkW9RfRTb4vMx3jtjoY0X0QkBRKo2YFPKHwEUXyEz4o7G1XbWpdFmf8fHAvVC eIZUgmn8E8jJLPiXelzoitwrpLFQf4TW2ALyKP2R2YuntD4TxgzKMqGDy2l4/2kb/Pk8WXHt 0tkEWEXQmA99MJJ2Liom8dCbJygXSoD/8NSibUAyzK3eDpi/w+Vm5Tt8sA0J0nwGH5u9Ra8s PRW98OGb6BZHEWEh7GC0kvRZza/e/0spBcp+exIhLlUuqmCQZKKrYSMthFmp5HCAGRv86wWV lBqmb+6/d4XLMithFBIG/WRVkJcuy4oRK+3xyBS0DysFbN4XL6I5JjPMK21IUxbCocb0wW09 Y1U4gUE3ucx0ip/AUCAm+x4rC5EIYKDIpS0hnQ6HZVj97rtmDk2p1+TXtFbADq3x1Cq8JE+N nvyab2Z/sRnIy2FTKyb59cKIe+dpvdIZ0WrZqn5tDoyGWP6d/0noMWjWLL6ReASp2dROrAet DU8gIAyibeTm5u5LMvr3u5sbmGN55t3N7f0wVOUpBCCzfRz2tizYfy569VFBdiPTXLLxBHnX ozXZWzvr1EBLte1/9UqhfvegLgRaLkliHdUoKwARAQABiQI8BBgBCgAmAhsMFiEEpIxP1q7u GfYdDsO1+vy+itnNHPkFAlwxJ6YFCQJjXNoACgkQ+vy+itnNHPkD0g/+NG4ZLCo4nX6VkMnD gcxB0OWV+u1WBYwZn8VMHBHX2orD4JfmlTezbmkvdL5UYLhHceICvr/qJ7xn0q0DZC7j+J08 +6iB+eu0W69j+y1CXKVuygcI+K2Yq49eXaZqwqDBbLMiCYll6uDfvOSKF4dCsNB52P5nQfLy eFd6177y3TxU3+EwrhAd63z4R5SXp4c5ylK9xMMoyDZA+oNtZ+YJ5A/Xm9SOXNT0CbHdqwTp tyz/o7rDbigd1FrP/R0jM30Knc8UgAcCsqO9WZokZNgoDUWZxDMs7W6XP54Yb3+JTAzssMkb QKmd6jy5S+4CSEbydT0Nth6ECMqfXTVinxSZnpzFAsqlLtM8S6qIgYrWZBfrd/AXTn6dDabt rcy0rNtF9WuB51THY3zywvqRruwkDRqVcmEHb/pxTrXz4WXBjpNTCHvnojJMjpSBzxj1Pbqt rNMUYwv9A+0WV2HMKHbDkE2asEsr+pthJw7+Bz5j8RGho7pp1XEYs/YIFbTsLPL7eJ7bEqJj skTr4iKVr/SLwdluueBm1NwIYAWrK++T7t6vE0yXq9pEvoF22Fx5BsulDmwvc887QwlRdDJv gtr/TzGCEpiaT7mW6mD1QuxIxuZ02Ewr7A5XZ/diFPrsVbN0jKmCQ4631kILI5EXKsagWkMU AwZoeZ3Xzxy7aap+/uQ=
Cc: cfrg@irtf.org
Message-ID: <b1fae97c-da97-9745-55cc-d396abe906a0@gmail.com>
Date: Tue, 26 Feb 2019 00:45:45 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <d53dd35f-dcb0-a562-d432-955dc30155b3@openca.org>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="dTG8GrN1BmqjkGFWHEtT3QXex4N7ZGaTm"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/yw1qglxD27M-Ex_9n0w2CiRNoxM>
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 08:46:03 -0000

> 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!