Re: [TLS] Enforcing Protocol Invariants

Jana Iyengar <> Tue, 12 June 2018 23:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 626C313100D for <>; Tue, 12 Jun 2018 16:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] 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 ShaTLfP53AIG for <>; Tue, 12 Jun 2018 16:25:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 74408130F1C for <>; Tue, 12 Jun 2018 16:25:13 -0700 (PDT)
Received: by with SMTP id d22-v6so1379033iof.13 for <>; Tue, 12 Jun 2018 16:25:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yI4J008qxFi15rLopRjspzoQeGkdmDL6Zt/AdBSM7R4=; b=swHGSyiGSrCYpLjzNNPYmqQggC34kKpiuG17pDWfDPnqNeX7hopAGfkjie+GRAdmCB ounvGbBFpH3iCSQJKIhPv9s4XesPTVvfVZFuPiXlLAERMidc5Lwj4oSM1p9vDQJ0SOuC kNIYEaTx6VreHzCZTn6TzCHYHuFesKhPaSONjnH/v5cZNdB9fwifQxMNjOtuQz95/cQU 8LPUiioHB5RAVqdRP0tIGrrEAG/Pb1nmxPhh68+wnrJSosgOYzCI843cwrfkHBElZpBB 5XpLRSbnPNWP7gLuAMKGrFdnVccGLfe5ikp4SZJPWIIxdxVeH23ble62nyBLUt+Wx596 auPw==
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=yI4J008qxFi15rLopRjspzoQeGkdmDL6Zt/AdBSM7R4=; b=HP0BdxvEHQDZNESJCaLVqo8m+5jG4dYMoXqwnIw0G9G5rKznK+B5BTQrjigMu3XoAd bDMmENT0+U1AWXW7c+r1Tp3PcQflctd3H35+MJdqF0e6sfSGG63ZnQDeOpfXFwKzqnoI BpI52bllpNCEwv5uCb/AK7pdodPHapPheEAvsjxv+cz17xxYxcQA8KC2R2Po7GUZn+Dz QnuVq8iWLPhiEVxIuKKVDffRbqYfQqFALK/VPDlQvFuj/kKlGLHEkbA4e5/VYZ/fQ8I8 xDiiJaEOVtwBnAEyfWCmulr5KlIdy5qlogU7ReAt3DtFxLjRQuBcSzliX2ARsjd6gt5D bXog==
X-Gm-Message-State: APt69E3Ucptd3sn8C66BGtO5y//HlqVBz/2tAwtb+ex9r3imjJvkFKis vwuLhktLrDwoxjrtqeN1H9j4kr8Qrgnc7qTm+Ss=
X-Google-Smtp-Source: ADUXVKJbn8lhbMQZHOPhMs6hBqZdaGWxU+5RD7JeFbnB1ULXjqzkJKYcwjUybbNIAJ0TNnm+w61kthsExm0QLPDVJSU=
X-Received: by 2002:a6b:1502:: with SMTP id 2-v6mr2668721iov.203.1528845912787; Tue, 12 Jun 2018 16:25:12 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Jana Iyengar <>
Date: Tue, 12 Jun 2018 16:25:01 -0700
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000008c54a9056e7a2d86"
Archived-At: <>
Subject: Re: [TLS] Enforcing Protocol Invariants
X-Mailman-Version: 2.1.26
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: Tue, 12 Jun 2018 23:25:20 -0000

I'm emerging from lurking to just say this: I think this is a fantastic
idea, and thank you for doing it.
FWIW and IMO, you're better off summarizing the codepoints you are using
and planning to use on a wiki somewhere instead of in registries, given the
timescales and the lifetime of these codepoints.

- jana

On Tue, Jun 12, 2018 at 9:28 AM David Benjamin <>

> Hi all,
> Now that TLS 1.3 is about done, perhaps it is time to reflect on the
> ossification problems.
> TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be
> incrementally rolled out in an existing compliant TLS 1.2 deployment. Yet
> we had problems. Widespread non-compliant servers broke on the TLS 1.3
> ClientHello, so versioning moved to supported_versions. Widespread
> non-compliant middleboxes attempted to parse someone else’s ServerHellos,
> so the protocol was further hacked to weave through their many defects.
> I think I can speak for the working group that we do not want to repeat
> this adventure again. In general, I think the response to ossification is
> two-fold:
> 1. It’s already happened, so how do we progress today?
> 2. How do we avoid more of this tomorrow?
> The workarounds only answer the first question. For the second, TLS 1.3
> has a section which spells out a few protocol invariants
> <>.
> It is all corollaries of existing TLS specification text, but hopefully
> documenting it explicitly will help. But experience has shown specification
> text is only necessary, not sufficient.
> For extensibility problems in servers, we have GREASE
> <>. This enforces the
> key rule in ClientHello processing: ignore unrecognized parameters. GREASE
> enforces this by filling the ecosystem with them. TLS 1.3’s middlebox woes
> were different. The key rule is: if you did not produce a ClientHello, you
> cannot assume that you can parse the response. Analogously, we should fill
> the ecosystem with such responses. We have an idea, but it is more involved
> than GREASE, so we are very interested in the TLS community’s feedback.
> In short, we plan to regularly mint new TLS versions (and likely other
> sensitive parameters such as extensions), roughly every six weeks matching
> Chrome’s release cycle. Chrome, Google servers, and any other deployment
> that wishes to participate, would support two (or more) versions of TLS
> 1.3: the standard stable 0x0304, and a rolling alternate version. Every six
> weeks, we would randomly pick a new code point. These versions will
> otherwise be identical to TLS 1.3, save maybe minor details to separate
> keys and exercise allowed syntax changes. The goal is to pave the way for
> future versions of TLS by simulating them (“draft negative one”).
> Of course, this scheme has some risk. It grabs code points everywhere.
> Code points are plentiful, but we do sometimes have collisions (e.g. 26 and
> 40). The entire point is to serve and maintain TLS’s extensibility, so we
> certainly do not wish to hamper it! Thus we have some safeguards in mind:
> * We will document every code point we use and what it refers to. (If the
> volume is fine, we can email them to the list each time.) New allocations
> can always avoid the lost numbers. At a rate of one every 6 weeks, it will
> take over 7,000 years to exhaust everything.
> * We will avoid picking numbers that the IETF is likely to allocate, to
> reduce the chance of collision. Rolling versions will not start with 0x03,
> rolling cipher suites or extensions will not be contiguous with existing
> blocks, etc.
> * BoringSSL will not enable this by default. We will only enable it where
> we can shut it back off. On our servers, we of course regularly deploy
> changes. Chrome is also regularly updated and, moreover, we will gate it on
> our server-controlled field trials
> <> mechanism.
> We hope that, in practice, only the last several code points will be in use
> at a time.
> * Our clients would only support the most recent set of rolling
> parameters, and our servers the last handful. As each value will be
> short-lived, the ecosystem is unlikely to rely on them as de facto
> standards. Conversely, like other extensions, implementations without them
> will still interoperate fine. We would never offer a rolling parameter
> without the corresponding stable one.
> * If this ultimately does not work, we can stop at any time and only have
> wasted a small portion of code points.
> * Finally, if the working group is open to it, these values could be
> summarized in regular documents to reserve them, so that they are
> ultimately reflected in the registries. A new document every six weeks is
> probably impractical, but we can batch them up.
> We are interested in the community’s feedback on this proposal—anyone who
> might participate, better safeguards, or thoughts on the mechanism as a
> whole. We hope it will help the working group evolve its protocols more
> smoothly in the future.
> David
> _______________________________________________
> TLS mailing list