IETF Logo Mail Archive

Re: [TLS] Enforcing Protocol Invariants

"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> Mon, 19 November 2018 11:37 UTC

Return-Path: <Hannes.Tschofenig@gmx.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129E7127133 for <tls@ietfa.amsl.com>; Mon, 19 Nov 2018 03:37:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.876
X-Spam-Level:
X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 epX_KVtDlXnu for <tls@ietfa.amsl.com>; Mon, 19 Nov 2018 03:37:26 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 ECF53126CB6 for <tls@ietf.org>; Mon, 19 Nov 2018 03:37:25 -0800 (PST)
Received: from [217.140.96.140] ([217.140.96.140]) by web-mail.gmx.net (3c-app-gmx-bs80.server.lan [172.19.170.228]) (via HTTP); Mon, 19 Nov 2018 12:37:22 +0100
MIME-Version: 1.0
Message-ID: <trinity-bec8e71c-eacb-4a89-8af6-d9f6b5c015a2-1542627442596@3c-app-gmx-bs80>
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
To: Ryan Carboni <ryacko@gmail.com>
Cc: tls@ietf.org
Content-Type: text/html; charset="UTF-8"
Date: Mon, 19 Nov 2018 12:37:22 +0100
Importance: normal
Sensitivity: Normal
In-Reply-To: <CAO7N=i0g9d9x5RdF_guKm3GDAxVRHSV+eHffs6kiJm6dWO7tvw@mail.gmail.com>
References: <CAO7N=i0g9d9x5RdF_guKm3GDAxVRHSV+eHffs6kiJm6dWO7tvw@mail.gmail.com>
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K1:Ool4QHlhCADEj1xk3niDdV12jh7SDpFsVRbVWS3vMNSV+spLMyhzvyza5lkwTdEF2enC+ Mq+bfCHqquAnuYtINzsN0UBEkoHS3NHhXez7g8l+Wz5SpSuOhVWyF6BW16q+l9yjykyiCz/nOl8M e4h0MQmkZy6zvtuVCHPhN+lOcYTCivqL1Z3z9AUwEFczwByVV9CWdCJilQYzr5fGruuvmFg7ob// rOjnO4zXkIh34gXuWDMxlhgjDEvsHCrLEy54k1GGkfb44P2Bj4hHt7o2GN/gmarxjdqs0zzr8Ran JQ=
X-UI-Out-Filterresults: notjunk:1;V01:K0:v4O6iPvT+VM=:1YqA6uCdhkni7CzPpKrvrP /N1RRpSXn6QW23VN4ETb514Oxv6VDBtFusZ/xeD8Ip4/kJVBsZ7tdCqduxFk0H0PQxCnWP0vh 4aLTHLgO4QIrNd1pEwD6uKTsLT5mzanGa/s/SYVIcoWbrRDF5QXsu9JU1U1uz7Q0k0Tmh4TE2 yRO+m3wg7Mtgg8uxNlm6MET5+GIERUbr1CeAfpnWg2b89TxcK/wzdQzALLn1xZ2H8J/9Cbvov 2sZvgpGuQMfbu10osUEXKVpz/6rW14w3djC3+tzJ3q35z9/PMr//e0YRLhKMu2DpQlwD2iMjO aWm3iVjC+kHvFtaMW3LaBUazEQflcKVXa2kZW9jJ0bTSN+KFyemQZZA6mclh8KDcvwSYW/RwE HAXtE53EvrS57CpO/rv+wBIXahISi3+qil9frML1jEHTniXnD0m722olQ9NHFlTL0SmtPejZx v2aA8Ek32BEAfkLm4AniceHeeRq0NJw2OZv+g3A/WoK7kv6+tgluLvvthh9Pqew2Zz5GQa7wm Pac+En4l7Jn5fe/ANILYwukxg/FpsC8ZcX7G4AcqeafuUgRJL2Aa3QWk94kkbEsbKkp2qRsVD Bo5VraJQ1kpFI=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mpbz84itU_Ks851ttc6OZNDXEYs>
Subject: Re: [TLS] Enforcing Protocol Invariants
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2018 11:37:28 -0000

Hi Ryan
 
reading through your email and the subsequent exchanges I am surprised that you show up right after years of standardization of TLS 1.3.
Suggesting ideas at the right time is somewhat important.  
 
Later in your emails you explain what you consider complex in TLS and some of the ideas you are suggesting are alternative design approaches. What standardization helps you do is to work out the details of these different proposals and then to compare the different approaches against each other. 
 
> The state of cyber security is a horrible disappointment.
... and most (if not all) of that disappointment has nothing to do with TLS. 
 
Ciao
Hannes
 
Gesendet: Donnerstag, 08. November 2018 um 09:44 Uhr
Von: "Ryan Carboni" <ryacko@gmail.com>
An: tls@ietf.org
Betreff: [TLS] Enforcing Protocol Invariants
Hmm. TLS has gotten too complex. How does one create a new protocol? Maybe we should ask Google.
 
The SSHFP DNS record exists. DNSSEC exists.
 
This might be a radical proposal, but maybe the certificate hash could be placed in a DNS TXT record. In another DNS TXT record, a list of supported protocols could be listed.
A DNS SRV record would define the port that one can use to connect to a service, because the URL scheme died after .onion was recognized as a domain and after chromium decided to that the presentation of sub domains was unimportant. So no browser has to show which port it is connected to.
Although, to be radical, all anyone needs is RSA-2048, ephemeral DH-3072, and SHAKE-128 as AEAD.
And maybe recommend that boot entropy could be obtained by using the timer entropy daemon for one second (and which would in theory provide enough entropy for perpetuity).
 
This isn’t rocket science. The state of cyber security is a horrible disappointment.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email