IETF Logo Mail Archive

Re: [TLS] Enforcing Protocol Invariants

Ryan Carboni <ryacko@gmail.com> Fri, 09 November 2018 18:20 UTC

Return-Path: <ryacko@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 9355312F1A5 for <tls@ietfa.amsl.com>; Fri, 9 Nov 2018 10:20:04 -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 6mhkz6TwgGE6 for <tls@ietfa.amsl.com>; Fri, 9 Nov 2018 10:20:02 -0800 (PST)
Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 C3A9E12D4EE for <tls@ietf.org>; Fri, 9 Nov 2018 10:20:02 -0800 (PST)
Received: by mail-yb1-xb36.google.com with SMTP id d18-v6so1424372yba.4 for <tls@ietf.org>; Fri, 09 Nov 2018 10:20:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7KHKWiWh5GO5KGQGQwyfqiRWaGZfQN+clYATQjb/ZP4=; b=VSqGCJ2XlvBR8K/lCY0wa6m1ts4TyOdJo5JUv1Y2OXEDrwZ8DzWobT5v/eF6aCBeTF W4jdp5TqNOoUR+tmukDET/Jvtn/Mm4zsKeCTPy01HTQHgl4nH/5YoEJgYoZBTiY2yFcH ZUTOckfXZWFCzBjmsfcKRvq5lyPSui4Z2h2MRHcD4mHg62feIoIvpgbC699eTypgwoWl er+lDyJA7Q4oeqb1ZDX8etaHFYuio/i3e9V9ECIrblqJGDhviHi61Y5tnlJ9KLuBO17O GqSZDWeQp+ewOphm3aZaN+d7UN3RRF+s8u+8GUOebA8gWpZRPb13j2XIC5nysUrCG3Vk A7RA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7KHKWiWh5GO5KGQGQwyfqiRWaGZfQN+clYATQjb/ZP4=; b=ibM0o47i7T8csjkKzpbXCLd0hiviwFMK+/WDWHaiENU3ZoOiQfweQjzJX9b2aec1AZ TzQYwAXMsdb3jIKoa6FmIowlxH2+XDa40XvliucDdl92K1ODDzgGKGpMszYjDaWD/Gyg 1i3ztpshmkiojhuQ7z2IwaP8DUnnfc4ODysN/c0BGn5K4L1HO40VjhJr47ZN8bMd7wzI pC4SKOGud9DTfvoX+gvDac3DG6qgqU3jXnNOjovcH1gYGLarKKiuJVTYTEUcxrfeNPgN WYSXBK5wwguKZ+GMkT8Pe/KcjiRe4veRb5MkOuIF+wXX3DFlAkF7AZz5/jewtopFV+1Y DITA==
X-Gm-Message-State: AGRZ1gLgNaOR4v6Y1KYDMUB4X/uLbLcMnnSPU0itnCeUeYG8VENRJJfW zi0U4owmxoY8PIU9meaRw6xpBRRda4kC2l+hiwRlwQ==
X-Google-Smtp-Source: AJdET5cHgvg54fPF8rBGMHtcBPtK/HcK3T3vCftbRmH/0LEdXjrtCvBHyBK9TXsFrDz1WsfsixPxohBCZ/gxKn74bEI=
X-Received: by 2002:a25:5342:: with SMTP id h63-v6mr9548419ybb.473.1541787602051; Fri, 09 Nov 2018 10:20:02 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a81:a014:0:0:0:0:0 with HTTP; Fri, 9 Nov 2018 10:20:01 -0800 (PST)
In-Reply-To: <CABcZeBNMVcidMGAE2XeSqpYRriUke_wmXvc6m5WVto7j6eM8vA@mail.gmail.com>
References: <CAO7N=i0g9d9x5RdF_guKm3GDAxVRHSV+eHffs6kiJm6dWO7tvw@mail.gmail.com> <CABcZeBPb2aPE3eXsqD5-qvWO88W=iMRxZ9YgCXZiTSGAPBDMxQ@mail.gmail.com> <CAO7N=i2L9mY1kdZNhgSV90e5FN64VBh0miApQv_9ws9fCdaGVg@mail.gmail.com> <CABcZeBNMVcidMGAE2XeSqpYRriUke_wmXvc6m5WVto7j6eM8vA@mail.gmail.com>
From: Ryan Carboni <ryacko@gmail.com>
Date: Fri, 09 Nov 2018 10:20:01 -0800
Message-ID: <CAO7N=i0Jd03PoppWgoY=n4UE7rwmwvtEn=ryuug8PfM+Bdr+qw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000056e5de057a3f66e7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OxDHEWvcaxid-utcJR6lm0mSjuU>
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 18:20:04 -0000

Okay, a modern browser connecting to a server owned by billion dollar
corporations are able to implement the latest version of TLS, I’ll concede
that. Regardless, I can only underline one point: any new protocol needs to
break both compatibility and be downgradable, and require a small amount of
code. It probably wasn’t wrong for the average browser implementation to
downgrade upon connection failure before, it certainly seem more sound than
any gritty details of recent protocol design.

Furthermore, TLS 1.2 is perfectly fine, and so is TLS 1.3 by everyone’s
statements. If so, a new protocol has no need to quickly replace either one
of them, but instead have a high likelihood of being superior and simpler,
and performs better according to current design of the internet.

And possibly list recommendations for how out of scope issues could be
resolved in a subsection for the inevitable RFC describing it. Boot entropy
can be solved by increasing boot times by one second. Reminders of various
Javascript functions to ensure authenticity. Etc.

Google’s idea to rush out experimental protocols looks disgusting to me.

v2.23.0 | Report a Bug | By Email