Re: [TLS] Enforcing Protocol Invariants

Steven Valdez <svaldez@chromium.org> Thu, 14 June 2018 14:35 UTC

Return-Path: <svaldez@chromium.org>
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 90CB9130DC0 for <tls@ietfa.amsl.com>; Thu, 14 Jun 2018 07:35:42 -0700 (PDT)
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, 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: 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 91enExBMrb35 for <tls@ietfa.amsl.com>; Thu, 14 Jun 2018 07:35:38 -0700 (PDT)
Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 AE33A12777C for <tls@ietf.org>; Thu, 14 Jun 2018 07:35:38 -0700 (PDT)
Received: by mail-io0-x241.google.com with SMTP id d185-v6so7367822ioe.0 for <tls@ietf.org>; Thu, 14 Jun 2018 07:35:38 -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=ElBKfLKNtrQlRdVIG5YDJmE9tHs6iAo/DIWKOaSiVUA=; b=nLgixoiW6KED8wwNhwCK7oEyXhaORN/x1dtYBdRzZB3rGNmwJXnEOGh4teM0UD86gj dLRk63EyCMlLUKghsiOBXvVI07a6Us6atRe3yi7n7QT3GumnKddYP7lGyfMemB/qbe8t /JFK0wVVl5UaSQo0D/TGw2lFaBVwvRSZ5++HQ=
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=ElBKfLKNtrQlRdVIG5YDJmE9tHs6iAo/DIWKOaSiVUA=; b=nZoBANs+QEQ6bi3vzNW4Lvz4hXuB+tRYs5Cr9caI+n1x7DnFqGcR0aF7igclGTh9M8 kaYPCHiRxuVPs7uZdsoYf+wg4/odgoCIWpgdg3iooCPTz9sdmHjH0bUinlkQ83QxVHyL ygdt6qSKhCvrCTbH5QsLhfX7FnINDwbuJU2c6BgGf/m0TqIBoq0H6xN88UtZxmndYfTh 3dOy3Jyn+XcMXtB5KjFRFafFCmSGo0E86PuUUsepxl2834VGLyDe//ypsdG0jvqoNX8G sAv75FDyM5BJhlUIRT9mfuBxk3dNIKTAkca/iYbUKEDzR+wjI8CUmOc6pQwerTCStx1w 4/kg==
X-Gm-Message-State: APt69E180J9VLQE3HnHZmet7sIJp0c3kZbFMaQJbAbeVEOSXwCHnkKoh Vjjx7BUn4dGv1vwkeBWMSvYvzP2UHQ4=
X-Google-Smtp-Source: ADUXVKJ19C5UwLYGrXukyuN2IXUvri4XnKo015pXEl6YSqR7NTxAOXslyr1rpBnBLv1EDMbm8Cr9Iw==
X-Received: by 2002:a6b:a282:: with SMTP id l124-v6mr2550901ioe.256.1528986937876; Thu, 14 Jun 2018 07:35:37 -0700 (PDT)
Received: from mail-it0-f51.google.com (mail-it0-f51.google.com. [209.85.214.51]) by smtp.gmail.com with ESMTPSA id 16-v6sm2894449itk.17.2018.06.14.07.35.36 for <tls@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jun 2018 07:35:36 -0700 (PDT)
Received: by mail-it0-f51.google.com with SMTP id p185-v6so9001339itp.4 for <tls@ietf.org>; Thu, 14 Jun 2018 07:35:36 -0700 (PDT)
X-Received: by 2002:a02:8aec:: with SMTP id i41-v6mr1437245jal.33.1528986936423; Thu, 14 Jun 2018 07:35:36 -0700 (PDT)
MIME-Version: 1.0
References: <CAF8qwaBfG2aQTMCTQ9=8Uj1yRB7PRAaZNeNQnTPtvboxfAh6HQ@mail.gmail.com> <MWHPR15MB1504162E7DCB6BADB8730D2AAF7D0@MWHPR15MB1504.namprd15.prod.outlook.com>
In-Reply-To: <MWHPR15MB1504162E7DCB6BADB8730D2AAF7D0@MWHPR15MB1504.namprd15.prod.outlook.com>
From: Steven Valdez <svaldez@chromium.org>
Date: Thu, 14 Jun 2018 10:35:24 -0400
X-Gmail-Original-Message-ID: <CANduzxB+d+_oznrrr7Q7wRM2D-b+YrK56C3J6-7uZc3+55N0fQ@mail.gmail.com>
Message-ID: <CANduzxB+d+_oznrrr7Q7wRM2D-b+YrK56C3J6-7uZc3+55N0fQ@mail.gmail.com>
To: Kyle Nekritz <knekritz@fb.com>
Cc: David Benjamin <davidben@chromium.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000036b7d0056e9b03b9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ecVHuxG3XEDlxQ28hEF4EpiSyVw>
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: Thu, 14 Jun 2018 14:35:43 -0000

This scheme probably isn't sufficient by itself, since a middlebox just has
to be aware of the anti-ossification extension and can parse the server's
response by decrypting it with the known mapping (either from the RFC or
fetching the latest updated mapping), and then ossifying on the contents of
the 'real' ServerHello. To keep the ServerHello from ossifying, you'll need
to change the serialization and codepoints of the ServerHello at each
rolling version.

On Wed, Jun 13, 2018 at 8:29 PM Kyle Nekritz <knekritz@fb.com>; wrote:

> I think there may be lower overhead ways (that don’t require frequent TLS
> library code changes) to prevent ossification of the ServerHello using a
> mechanism similar to the cleartext cipher in quic. For example, a client
> could offer an “anti-ossification” extension containing an identifier that
> corresponds to a particular key. The identifier->key mapping can be
> established using a couple of mechanisms, depending on the level of defense
> desired against implementations that know about this extension:
> * static mapping defined in RFC
> * periodically updated mapping shared among implementations
> * negotiated on a previous connection to the server, similar to a PSK
> This key can then be used to “encrypt” the ServerHello such that it is
> impossible for a middlebox without the key to read (though would not add
> actual confidentiality and would probably involve aead nonce-reuse).
> There’s a couple of options to do this:
> * Simply replace the plaintext record layer for the ServerHello with an
> encrypted record layer, using this key (this would not be compatible with
> existing middleboxes that have caused us trouble)
> * Put a “real” encrypted ServerHello in an extension in the “outer”
> plaintext ServerHello
> * Send a fake ServerHello (similar to how we encapsulate HelloRetryRequest
> in a ServerHello), and then send a real ServerHello in a following
> encrypted record
> All of these would allow a server to either use this mechanism or
> negotiate standard TLS 1.3 (and the client to easily tell which one is in
> use).
>
> With the small exception of potentially updating the identifier->key
> mapping, this would not require any TLS library changes (once implemented
> in the first place), and I believe would still provide almost all of the
> benefits.
>
> *From:* TLS <tls-bounces@ietf.org>; *On Behalf Of *David Benjamin
> *Sent:* Tuesday, June 12, 2018 12:28 PM
> *To:* <tls@ietf.org>; <tls@ietf.org>;
> *Subject:* [TLS] Enforcing Protocol Invariants
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__tlswg.github.io_tls13-2Dspec_draft-2Dietf-2Dtls-2Dtls13.html-23rfc.section.9.3&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=SaWplkxkbv9O_Z71HdE6L71vu2f7ovWWaEQrPRRbywc&s=F7IJ9Nac5Of_GCvBVk0_QhTplCJjoboBSemHl0pi1oM&e=>;.
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtls-2Dgrease-2D01&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=SaWplkxkbv9O_Z71HdE6L71vu2f7ovWWaEQrPRRbywc&s=tcAlu2fEfkKjM2l4WBCCRosOGV3DMAQcHvh8Pe38K5w&e=>;.
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__textslashplain.com_2017_10_18_chrome-2Dfield-2Dtrials_&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=SaWplkxkbv9O_Z71HdE6L71vu2f7ovWWaEQrPRRbywc&s=owCJbXs1BznTLdshoZZA1ho_g9w_m27PlfWut3dMRpM&e=>
> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls