Re: [TLS] Enforcing Protocol Invariants

Eric Rescorla <> Sat, 10 November 2018 10:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE007130DD9 for <>; Sat, 10 Nov 2018 02:30:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xU5itUSg3Vm4 for <>; Sat, 10 Nov 2018 02:30:39 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 702C8130DBE for <>; Sat, 10 Nov 2018 02:30:38 -0800 (PST)
Received: by with SMTP id k19-v6so3662461lji.11 for <>; Sat, 10 Nov 2018 02:30:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e8xN9wD5kmRcDGjHfiNSHhwKxAOVEyMKbx/Iyph4nqo=; b=nlmpSdIpOuYlnm349BSbkIn5lE+lgoDXYp+g44CKogHSQnOyhI8ChMU5WJckONhevT Ug5MaoqWMj1j3RISTFbRvf32MZQTGZOOGWQdnDYajfUIpv5fHrtl48Xm8fnTUbmvXPtn Iq46HWKUAebhL6d8ZM8K89FGO5mekmfyrPZaIopmQ5HfjDmvDUuqegLbBEdUtDxunkX7 X0sTHuRZkbr/0gkuBOV8CfFLt7bCJ8jl1vx5uwMVmNvweCWY4HzfN5389MFg6V7zQguE bj+tvgEnfwBHVYrbM+bilKsTEhWqzT65+dcuJ5T+w/693Q1/sfsD1jvectfzegzMF0Y1 e3sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e8xN9wD5kmRcDGjHfiNSHhwKxAOVEyMKbx/Iyph4nqo=; b=sIbP59Tu/WGDqH5SELyLrk+lJTDrJQ8CwIAiKeCOPESydtfbIL9oFGsB/jT18uNKO9 qdCPUpmTyS2CGOhbtfOlDBngslJex6T/Cb5q8+8gEw9rlG6VX4RTBr7ruBhByVOOmZLi PCbfR086YIQnRhWofGY2W3YGNh6iULD3E/R+XGvDP28qL05eSiF7ZZntvMEDyv0eKshH EOfO5UUBx/gbSh4hawoaiMHaqGQY2DLbBMQCwblBrtsOkqkLUEmCWb9cTlmoZB+UAdgj ZMaPid8FT5rZmVsnKMzdFAy7L3uj/gusW9dMEzpblvA09H46GQEnRBPtE1lJkVJdRRnm XzcA==
X-Gm-Message-State: AGRZ1gKFnERMJMJ6vJty5UGTVzQs8XNbysCuG1HA1NOjVD2qNFHkiRAh AmhexwieyzD7pR7DjE7J4z4YAF3rDaSJTThgrcBK5lvkKZ8=
X-Google-Smtp-Source: AJdET5c/vuRRkX5/OYBXPE+QAqKoNdWJrhc74szr88go0XoHOV2Q4Diug24pm4bpK7xKzv6drEHIwZQTO5hP3pxK3/E=
X-Received: by 2002:a2e:5418:: with SMTP id i24-v6mr8318486ljb.51.1541845836632; Sat, 10 Nov 2018 02:30:36 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Sat, 10 Nov 2018 02:29:59 -0800
Message-ID: <>
To: Ryan Carboni <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="000000000000642d62057a4cf59d"
Archived-At: <>
Subject: Re: [TLS] Enforcing Protocol Invariants
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 10 Nov 2018 10:30:41 -0000

On Fri, Nov 9, 2018 at 10:20 AM Ryan Carboni <> wrote:

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

This thread seems like it has drifted afield of the TLS WG, which is
chartered to work on TLS.


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.