IETF Logo Mail Archive

Re: [TLS] Enforcing Protocol Invariants

Lanlan Pan <abbypan@gmail.com> Sat, 17 November 2018 11:09 UTC

Return-Path: <abbypan@gmail.com>
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 27FC0130DC7 for <tls@ietfa.amsl.com>; Sat, 17 Nov 2018 03:09:30 -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 TnzvNB9CMsQl for <tls@ietfa.amsl.com>; Sat, 17 Nov 2018 03:09:28 -0800 (PST)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 EC51F130DC6 for <tls@ietf.org>; Sat, 17 Nov 2018 03:09:27 -0800 (PST)
Received: by mail-ed1-x52a.google.com with SMTP id b34-v6so21651289ede.13 for <tls@ietf.org>; Sat, 17 Nov 2018 03:09:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hnEAxERyWiTortUC68hIdOqkxS1h3/FJT+DwmiC74qY=; b=jfOgHdkKAbSHqatj13nqEVmDhLdZE2tarn8+Q/5hfYYyylbn0u47LKkcVkQc+y4w6y fXGLz3SfwUXHdibuhwCoQQTGqMZF+mVt2L2c//zYomOMnHZ9JVb4J4YAUa00gDl01bcj 5raSGf/RQ2d3hhMbQCxMqxLByX10sUllxdeScPZrrtn/fFOmp3b1LVrEehD6BhhXG6tl Sbc93PRjoQHmThm8KFsaYa9aeRpys2R138laWFbsbhBmFZg6PfV5DHbEczGq3vJvaHOA vBLRil55mftLxJMeBQKPiEMk7+1kib4HCy7weIbNy+SDO9oUUahRbqKVfjMfimb9ZUr8 EYFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hnEAxERyWiTortUC68hIdOqkxS1h3/FJT+DwmiC74qY=; b=dYY7VGM5MjHSk4BZVXfOLUCwR7O04LdBvBNWC0z+vHazdePqp4Td7Hz8uFwbo2bLm0 bd47L3b79+somuWUQSgzQVxc0w3DbHwL2F5wk8YCV7D22iF4BLvKR3S7lagYbs0QAJVJ UHFxWy2GHeP8V1K3hr3lIa81o7YEx7BGHy8AZx2yGZu7P4GuFLKtHN0CFA502pPF3JT7 10fAg/6lz9J1NVVe6e7mCIdmOE6SDXSnfJHIG02/DmqqcS2fFukoQ3NIuK9LaEPj6ics NzVG1XqtquBRBC9Z8sv3xc8QJ/Dxf9y+3fzE7waIKxZZaHQ2L/E2/iqYi5swqSfXDRgy 1AdA==
X-Gm-Message-State: AGRZ1gKzWiNDfXJkXcgjjueZwgA3dCspdMiYlRnejWYunyQr53eSIAs2 K5PzlEDEZvUYvre8kRsuiqxTyo2jGxTwhl1TaoY=
X-Google-Smtp-Source: AJdET5e7O4JyxjG+yGpeSqy3A8jvY71VwyL47ivaAz3BPv+AkGn92JbaOUFePNXt4XaJ8ZdX6jPlgjGIwJ0DK/mPgmA=
X-Received: by 2002:a17:906:b799:: with SMTP id dt25-v6mr11371582ejb.217.1542452966257; Sat, 17 Nov 2018 03:09:26 -0800 (PST)
MIME-Version: 1.0
References: <CAO7N=i0g9d9x5RdF_guKm3GDAxVRHSV+eHffs6kiJm6dWO7tvw@mail.gmail.com>
In-Reply-To: <CAO7N=i0g9d9x5RdF_guKm3GDAxVRHSV+eHffs6kiJm6dWO7tvw@mail.gmail.com>
From: Lanlan Pan <abbypan@gmail.com>
Date: Sat, 17 Nov 2018 06:07:42 -0500
Message-ID: <CANLjSvXD9_u1UDkRkaNc8fnr=iQYKq73c8j9huMEPnH0XzuU0Q@mail.gmail.com>
To: Ryan Carboni <ryacko@gmail.com>
Cc: tls@ietf.org
Content-Type: multipart/alternative; boundary="00000000000022fc66057ada51d3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/POAsASEOnOLHQFNuaQypLCaWQlo>
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: Sat, 17 Nov 2018 11:09:30 -0000

Personally I think the low rate of dnssec deployment on SLD authoritative
server and recursive resolver is the problem.

And TLS's distribute certificate exchange maybe better than DNSSEC's
centralized trust anchor.

Ryan Carboni <ryacko@gmail.com>于2018年11月8日周四 下午4:44写道：

> 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
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

v2.23.0 | Report a Bug | By Email