Re: [TLS] Enforcing Protocol Invariants

Eric Rescorla <ekr@rtfm.com> Fri, 09 November 2018 01:04 UTC

Return-Path: <ekr@rtfm.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 F386A130DC1 for <tls@ietfa.amsl.com>; Thu, 8 Nov 2018 17:04:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 PMj7pOjGloDK for <tls@ietfa.amsl.com>; Thu, 8 Nov 2018 17:04:49 -0800 (PST)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 6D05B12F1AB for <tls@ietf.org>; Thu, 8 Nov 2018 17:04:49 -0800 (PST)
Received: by mail-lj1-x22a.google.com with SMTP id g26-v6so150361lja.10 for <tls@ietf.org>; Thu, 08 Nov 2018 17:04:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R9D+XoZ4PoKY/Vv7jfou5ShcKtJ2lrNGDlgfmo6AJZc=; b=MVEqGsFh4ogE7w/cI8WFrsm76amiYdrimX7lZuB+jj5DCYpgit0y+OIgK/z25Ajdvi HXeuN/XcaJhWP6QLyejRQLQN1DeHy6qKfZ3smbPZeDDOSUgckgCBNoUlTcejapJr6Ezh Xdxrtk42Lt7zkYJkHDgbItwAWS19B9cBoN4OM1EdDRdg1W4IxJtsAPOS6lVH0QX3W4YL FQQ9C/phWejUXDeVRQG14kdxh2w+9rb7pu2I9OrAoNJfw4TpjGV0LQSDQDzoEq9YXwzs iZ+Umprb6wh3cRB3O8KUyBHEt39ibozTvzmNL24JNtSoaN1iP3Jm1H1FAwnwM2Y4ANLc BXtQ==
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=R9D+XoZ4PoKY/Vv7jfou5ShcKtJ2lrNGDlgfmo6AJZc=; b=jhOaLnBU64B+/XKdy/GrP6uFKsxh2o9pDFsgp+ICOBeN28Cg/jxh4DTVLlcDBKUBfb nDyMBtc0vbPflOv/XZY1zQ3X753p1cN75kGK3K3aI7dTZzrGeapqKxVZz9XKBoorqTIY I/ZkYv6+DTLRwstaUkjjJlfoEXXVD1W+3T3reKcnrlAHNSveVeKKYiUtT3FtZu1nO1J4 mN800Fx0nqxlKGBcs2dx4wP2+1QRKJbLLPeUPiFskqsos5DetLkjrvottVB9i7DsbNSS glK9ctBj0F584kW9TG5AFHNVlA0vqvBx9BvayjtYrLZj1E10AJGmgEC+REJMTNtFGK4d SO7A==
X-Gm-Message-State: AGRZ1gIIi+GvJwCUDvo42xyvgKzomoCR2A667QGmecoZOtmvF0798Kpa 0XMq6koBvmxHxfy1Yp3lLsaHzGXqP9z8Pqb97GYptQ==
X-Google-Smtp-Source: AJdET5f8QrD6K/fj8iQM9sUc15FVd8xFVcnRoMMqx4ToBhZ9eGfFJVWfuqnQgYgZVV96HHR1sS8TS1rF3GpWLmdhDCA=
X-Received: by 2002:a2e:5418:: with SMTP id i24-v6mr4568768ljb.51.1541725487450; Thu, 08 Nov 2018 17:04:47 -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: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 8 Nov 2018 17:04:10 -0800
Message-ID: <CABcZeBPb2aPE3eXsqD5-qvWO88W=iMRxZ9YgCXZiTSGAPBDMxQ@mail.gmail.com>
To: Ryan Carboni <ryacko@gmail.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000560fb057a30f0f8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WjV9eWmGy9hSHUddGWCnfWjecQo>
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: Fri, 09 Nov 2018 01:04:52 -0000

Hi Ryan,

Thanks for your comments.

On Thu, Nov 8, 2018 at 12:44 AM Ryan Carboni <ryacko@gmail.com> wrote:

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

There's actually an RFC for this: https://tools.ietf.org/rfcmarkup?doc=6968.
Unfortunately, it is not really a viable option for replacing the WebPKI
for TLS for two reasons:

1. A nontrivial number of network elements will not correctly pass DNSSEC,
and so attempting to use it will cause failures.
2. Essentially all clients and servers only support WebPKI authentication,
so at least for existing applications (such as the Web), endpoints will
need to support WebPKI for a very long time.

There are some specific applications that could potentially use this
method, but that's not going to work for most applications. It's also worth
noting that in practice, many sites are served on multiple CDNs which do
not share keying material. This is a real unsolved problem for Encrypted
SNI and would also likely be a problem if the keys in question were
endpoint keys.


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

This is an orthogonal question to TLS, I believe. However, in general at
least the Web community has decided that it's not excited about SRV.
However, at least on the Web, the reason for the ubiquity of 443 isn't the
inability to indicate the right port in the URL (which has a slot for
this), but rather that other ports than 443 have much lower middlebox
penetration rates.


Although, to be radical, all anyone needs is RSA-2048, ephemeral DH-3072,
> and SHAKE-128 as AEAD.
>

This is a fairly surprising proposed set of ciphers, given that the
Internet seems to be rapidly moving towards elliptic curve. This proposal
would certainly have very significantly worse computationsl performance
than the mandatory TLS 1.3 ciphers.


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 also seems out of scope for TLS.

-Ekr