Re: [TLS] Enforcing Protocol Invariants

Daniel Migault <daniel.migault@ericsson.com> Wed, 13 June 2018 19:15 UTC

Return-Path: <mglt.ietf@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 66B0212426A for <tls@ietfa.amsl.com>; Wed, 13 Jun 2018 12:15:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 nwpE6BK0Xwsl for <tls@ietfa.amsl.com>; Wed, 13 Jun 2018 12:15:55 -0700 (PDT)
Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (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 6A566130E87 for <tls@ietf.org>; Wed, 13 Jun 2018 12:15:54 -0700 (PDT)
Received: by mail-lf0-x244.google.com with SMTP id i83-v6so5641064lfh.5 for <tls@ietf.org>; Wed, 13 Jun 2018 12:15:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2ujyfzdpW9Vbgxv0eOwTCza5if5M++x1/rHMevkSLjk=; b=MJwppg6biZa0SjlZ14Y9mSY6FT9xcAi/Br7N13tSJGZJ1LMXY403xMsETQ88YXcGj2 haC13VEhyisdJ1D/UmoE4PFXpIgBsymCyW/pxCEWIsZ8pZjUeuSfqaaWQ2+ZlUwseM0J 0fs0YwRwVutx54SVzGN1V5DYhUaV+Czlr1wNhmy6Jvsn1Ji9YsoMCxNKgyBI/v4B6CXF MmA+NCEU5WVT62TOqlAYUWEzjkrfmrbydBowmOuhJ27rpq5ee9GbKSQjUkHQW503f+94 ubBAQIEEbMsuyBTCM0pwVUpNcc3E9W/aQXVWVbk49gZqq5ZkXABfDsZaPhToSJ2jX8be b3iQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2ujyfzdpW9Vbgxv0eOwTCza5if5M++x1/rHMevkSLjk=; b=W174A/vaoy+jjoNc2H3t2SZ56jcHtpeLrHv95neTGnhWwns7xiR6JoAaKXSZlgyUHr lJ1fMA/6fBm/4xA8fiKbijlgJ670qZ7+Bt8d0Ow+6mAv7nxS98p2EoSqxyCezHTaALe+ 4DZg5UEX+QfqdrKQfn60wOuMCQ6KVzOg2pl4jiFiif9ZC9h06SoD4k3OY5qMO/UauL9m PFoUNLDKgHm4VD6fikf1mJnNOeOhEvlSzhxhcwaMKQDWjU5sI7luSUBksBIx7C7QDsaS TO/ZUG2dNsbbAkx0izFvcA0bnv1kDGNGRSef4itJQEs6VD7yQP0aYqlk8HQcxSeDBXjh 2e1A==
X-Gm-Message-State: APt69E1AlUBMR7+Uu5ozVTjQd4S/Yl6ShkoDneQcvoN/ubQcy5MsF2AL YN0JbR0Ev9Qg4KV1+Cq5ahGFaD8sDS/9vqWMuGk=
X-Google-Smtp-Source: ADUXVKLkLFSU45CBTd9XXT0LstXjeB27DMsnd1DkbUjWxwdcxH+BBE41BM+qa8jhyhp0YCfQpM6EJ980QOY9Sb8p+gM=
X-Received: by 2002:a19:14ca:: with SMTP id 71-v6mr4085300lfu.126.1528917352595; Wed, 13 Jun 2018 12:15:52 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 2002:a2e:2e1a:0:0:0:0:0 with HTTP; Wed, 13 Jun 2018 12:15:51 -0700 (PDT)
In-Reply-To: <20180613180603.GA27662@mandy>
References: <CAF8qwaBfG2aQTMCTQ9=8Uj1yRB7PRAaZNeNQnTPtvboxfAh6HQ@mail.gmail.com> <20180613180603.GA27662@mandy>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Wed, 13 Jun 2018 15:15:51 -0400
X-Google-Sender-Auth: C9t9CzaqcvIHUcoi81-__BwK-BY
Message-ID: <CADZyTkmKtCmXh3Mug_K-TJDvmPf2DUybpocN8PTZa7o+A-qNbA@mail.gmail.com>
To: Alessandro Ghedini <alessandro@ghedini.me>
Cc: David Benjamin <davidben@chromium.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b14648056e8acf25"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Do8Vf6RO2EWZxes9T1mL6RwuS90>
Subject: Re: [TLS] Enforcing Protocol Invariants
X-BeenThere: tls@ietf.org
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." <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: Wed, 13 Jun 2018 19:15:58 -0000

I also support something is being done in this direction. I like the idea
of taking ephemeral non allocated code points.

What is not so clear to me is how GREASE prevents a buggy implementations
from behaving correctly for GREASE allocated code points, while remaining
buggy for the other (unallocated). code points.
Yours,
Daniel

On Wed, Jun 13, 2018 at 2:06 PM, Alessandro Ghedini <alessandro@ghedini.me>;
wrote:

> On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benjamin wrote:
> > 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
> > <https://tlswg.github.io/tls13-spec/draft-ietf-tls-
> tls13.html#rfc.section.9..3>.
> > 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
> > <https://tools.ietf.org/html/draft-ietf-tls-grease-01>;. 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
> > <https://textslashplain.com/2017/10/18/chrome-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.
>
> This looks interesting and I very much agree that we should do *somthing*
> to
> try to avoid the pain we've seen with deploying TLS 1.3 for future
> versions.
>
> We (Cloudflare) would be happy to help with developing and deploying it,
> and
> see how the experiment goes (and maybe even help put a draft together if
> needed,
> if that is the form this proposal will take).
>
> Cheers
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>