Re: [TLS] Enforcing Protocol Invariants

Tony Arcieri <bascule@gmail.com> Mon, 12 November 2018 19:16 UTC

Return-Path: <bascule@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 55E07130E4B for <tls@ietfa.amsl.com>; Mon, 12 Nov 2018 11:16:07 -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 u5pZ2HJkND5t for <tls@ietfa.amsl.com>; Mon, 12 Nov 2018 11:16:05 -0800 (PST)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 223E4126CC7 for <tls@ietf.org>; Mon, 12 Nov 2018 11:16:05 -0800 (PST)
Received: by mail-oi1-x22c.google.com with SMTP id e19-v6so8103918oii.13 for <tls@ietf.org>; Mon, 12 Nov 2018 11:16:05 -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=Cv7Ko908JdBnjKUUHqsEjaL79bxaIc72O7GO29sa8Nk=; b=Bv1PQCyoeGrFw/hTrJ+StuPzyzZYyCWzo+cHvf4oTe7k4nB86fsFEOAHfdaw6/YLQT nX9w02rSnjW6TK/hri+RO034rPw/+36qKKAGC6fFkmc8+bxxmGPfimdNgozkVsr2uzlE bkYF7dZCY4y/CPLaKyCfuOsZHOKEbxpHc8X8gL3z6i9luq7OO7ijDG138XpUWgeRvEGn hsSAihwEyprVEKa8BTqQH5zcc0cg7O7UbxNx1gWO9wKWX7WRZB9iDPNCWRGWQ1ByVmwJ onI6gMWJSPwa0VL3GmGVShffNgc7ac9FYaqISFXDvv+lnuc9uItXS5efSsHpKyvuChYj vb0Q==
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=Cv7Ko908JdBnjKUUHqsEjaL79bxaIc72O7GO29sa8Nk=; b=dCNQHIFqecQ65CyAW16VKaRSg0PWF8omdDjSyy88YJvrjfTRjmzFmyuIVYaNR62bY7 xQ+nTUcZ3pFdP+ro/Yhs935FRvyf1kFXJwmuvBlmhe/jLXTUszRX0xcBsA6fc6EfQMKi FIdJd0Bu4HMheodFQCubMD6h6mzIPxqfFvnSt/iNxyp35gQ+Ra2vDw/rfvVG1fN/MOpJ iPwXRy8PY2GCSmU6B6u38Eys5CiZcdDfPQJTSR2QlgNQHOheC3QY4NWUMDoEdDyvTGTs cJn38ZK5XMcvs6QDC66jVgQsCzdUO8IRbf2HGp8CfT9TvwDyBTbbAg7ou9c0+9u0N1Ne l1Ug==
X-Gm-Message-State: AGRZ1gK/PDpZebHVlBMM2uOHPJBOgAQw/96PBGr1wqRScrMMvNo/VDJp HZ4AtH02boMZ6emiqP1CG7goqrisFZpdvuV04no=
X-Google-Smtp-Source: AJdET5c3WvdwKnwNSBPe9LwnY/C+QyXoTTCIxycs7wZhLMhuG/LqwfRnazqZWOfFrdqUEv2uTDjdqQ38kTLx7X2gW9I=
X-Received: by 2002:aca:c108:: with SMTP id r8-v6mr1313604oif.258.1542050164301; Mon, 12 Nov 2018 11:16:04 -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: Tony Arcieri <bascule@gmail.com>
Date: Mon, 12 Nov 2018 11:15:53 -0800
Message-ID: <CAHOTMVKrfbmxJ-gk+dR_XaozjX=BJqmEpmHEFAs2GuMi4MBMMA@mail.gmail.com>
To: Ryan Carboni <ryacko@gmail.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000044e4d4057a7c8820"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PV0Ktk1QoLCD2B9bOBxc_Ufuhg4>
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, 12 Nov 2018 19:16:07 -0000

Ryan, I'm having trouble finding anything you suggest which isn't
significantly inferior to what's in TLS 1.3 at best, or bewilderingly
confused at worst.

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

The cryptography employed by the X.509 PKI is substantially more modern
than what's in DNSSEC. Much of DNSSEC's security comes down to 1024-bit or
1280-bit RSA ZSKs.

Furthermore DNSSEC deployment in general lags behind the X.509 PKI
significantly. In general attempts to bolster browser security with DNSSEC
have failed due to DNSSEC misconfigurations or outages.

Regardless, if your goal is to make TLS less complex, shifting from the
X.509 PKI to a DNSSEC/X.509 hybrid seems diametrically opposed to that
goal. And that's the best that you can do, as you can't just wish away the
X.509 PKI.

This might be a radical proposal, but maybe the certificate hash could be
> placed in a DNS TXT record.
>

How about instead of that, DNS can be used to deliver a CT log inclusion
proof?

https://github.com/google/certificate-transparency-rfcs/blob/master/dns/draft-ct-over-dns.md

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

Both RSA and traditional FFDH are difficult to implement in constant time
due to their use of bignums, making both notorious for side channel attacks.

Due to its reliance on large random primes, RSA key generation is fraught
with peril.

BB'98 is a recurring problem, and affects not just key encipherment but, in
conjunction with other bugs, also affects PKCS#1v1.5 signatures (e.g.
BERserk). At least TLS 1.3 adds PSS support, I guess.

Elliptic curve cryptography is faster, easier to implement in constant
time, and has comparatively trivial key generation.

For these reasons elliptic curve algorithms are preferred in modern
protocols. By sheer volume, we see many, many more attacks on RSA than we
do on ECC, and the attacks are mostly not novel, but the same sharp edges
coming back to haunt us over and over again. The surest way to avoid BB'98
is to stop using RSA.


> This isn’t rocket science. The state of cyber security is a horrible
> disappointment.
>

Your suggestions are not improvements, they are regressions, or simply do
not make sense.

-- 
Tony Arcieri