Re: [TLS] Enforcing Protocol Invariants

David Benjamin <davidben@chromium.org> Wed, 13 June 2018 20:30 UTC

Return-Path: <davidben@google.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 2A8D9130E91 for <tls@ietfa.amsl.com>; Wed, 13 Jun 2018 13:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.251
X-Spam-Level:
X-Spam-Status: No, score=-9.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 8Lj2mi9BCNic for <tls@ietfa.amsl.com>; Wed, 13 Jun 2018 13:30:12 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 F3F07130E27 for <tls@ietf.org>; Wed, 13 Jun 2018 13:30:11 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id x34-v6so3717706qtk.5 for <tls@ietf.org>; Wed, 13 Jun 2018 13:30:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TqzgT82wgMLXgNZCqCG9SWYKUmfjGiVtXMNferMU1Fc=; b=DxtNV10owi1lkWOTe9v63NCpfRvpY9mlO6tSwcpTi8c9hOen5IGiG2MrF3nAdez4Px ryzRe10kkbMxyqe+iQrQjZJURAiX+xt+xovVSY9vJhpkyKVzH+/Qjhk1RGCh1tFEwOQQ ayLoHVB+GwzgZAIP3euyhsmSzXBsu/A5jUpGs=
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=TqzgT82wgMLXgNZCqCG9SWYKUmfjGiVtXMNferMU1Fc=; b=lODr2NvV8vDVSucT96pL7FMJ4k74/u4734xyBCjl3l+8H1kBr7xnaJEaAHhF6IHz41 dNaWHuHeh8k+2wMBEEfwxdWL9t2YMTK2yy9mdL3Mz0wO8QnZ+CWv1iHJEzax2BXGidhk zTJcNbDKzatemlF4yAT51Ac3CWMiONdoeIISWQwrADK24GKvNIa1UThr4iPKzsvq05yw 5jFXwizUVjO9mmYcZwdSSshPC23ViM0z8PKLmPXtO9yB1g5bmNXGSRVUQuKAFucLWt7d Jb9tzOpn/6UuvtDQbAI7KWqfu2Uzeotsc42/vgR/gOc1c9v2d8wztXJepWgPtC33aQR1 kUOQ==
X-Gm-Message-State: APt69E0RLoR4Y9BIuJSTrUaxPOrpT1fNivVWfz/UecKPFvuMTjqNaYKk helJFzSayWWt6lOmjba9muIDA4DFu1nL8M3g01aF+hI=
X-Google-Smtp-Source: ADUXVKJdDEh03p4JeZaXE9jOgOgoTpw+1OEMjT7KQACWGdczRNW9d5yVDRwed8QdPYSeMTMkGh6d8U5OFH6dptv3PoI=
X-Received: by 2002:a0c:ada5:: with SMTP id w34-v6mr6084293qvc.58.1528921810910; Wed, 13 Jun 2018 13:30:10 -0700 (PDT)
MIME-Version: 1.0
References: <CAF8qwaBfG2aQTMCTQ9=8Uj1yRB7PRAaZNeNQnTPtvboxfAh6HQ@mail.gmail.com> <20180613180603.GA27662@mandy> <CADZyTkmKtCmXh3Mug_K-TJDvmPf2DUybpocN8PTZa7o+A-qNbA@mail.gmail.com>
In-Reply-To: <CADZyTkmKtCmXh3Mug_K-TJDvmPf2DUybpocN8PTZa7o+A-qNbA@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 13 Jun 2018 16:29:59 -0400
Message-ID: <CAF8qwaAkxteWLeG_SRnMWTz_7mmmJTrwat52uPKWPgtXW_CWYw@mail.gmail.com>
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: Alessandro Ghedini <alessandro@ghedini.me>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006e3a2d056e8bd9fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xvGJccgGJ4lQVZ8kt23-BNJOHI4>
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 20:30:16 -0000

Are you asking about this new proposal (which still needs an amusing name),
or the original GREASE mechanism?

The original GREASE mechanism was only targetting ClientHello intolerance
in servers. It's true that it uses specific values, and indeed there is
nothing stopping buggy implementations from treating them differently. The
thought then was ClientHello intolerance in servers is usually just
accidental. It takes a certain willful ignorance to forget the default in
your switch-case, and then go out of your way to special-case things,
rather than recheck the spec as to what you're supposed to do. It was also
meant to be lightweight (a one-time implementation cost and a one-time
allocation). It's imperfect, but it does seem to help with the problem.

This new proposal is targetting ServerHello intolerance problems. Rather
than fixing a set of values initially, it regularly rerolls random values
over time, with no fixed pattern. It should hopefully be more resilient to
this sort of misbehavior. On the flip side, it is more work to maintain and
only implementations that update sufficiently frequently can participate,
whereas, in theory, anyone could deploy the original GREASE.

On Wed, Jun 13, 2018 at 3:15 PM Daniel Migault <daniel.migault@ericsson.com>;
wrote:

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