[TLS] Keeping TLS extension points working

David Benjamin <davidben@chromium.org> Mon, 25 July 2016 22:32 UTC

Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C641F12DA5D for <tls@ietfa.amsl.com>; Mon, 25 Jul 2016 15:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Status: No, score=-3.986 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id eQLhSCfmzALG for <tls@ietfa.amsl.com>; Mon, 25 Jul 2016 15:32:41 -0700 (PDT)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 88A1F12D578 for <tls@ietf.org>; Mon, 25 Jul 2016 15:32:41 -0700 (PDT)
Received: by mail-lf0-x235.google.com with SMTP id f93so138298909lfi.2 for <tls@ietf.org>; Mon, 25 Jul 2016 15:32:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=YBcZy9tsBtKFnkYW4YNuh5uPI/tDFSAUwLnYOuH8LAY=; b=NH4ijZv+9Q7tg86Q5HXyvQynPqFnRzJypUvAcQBcYdwM1BDYG18fJvndiWQoapobOt OnAEL1Tr20qo+T7cUiQ2iAYjdGxE3z0C2ihiL78VvnQx0xJWyjKwgG/XH8RILuoX8f6Z QGt7BKQbO7dq4cxu4s921Cam4XjsZz5i4iTAw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YBcZy9tsBtKFnkYW4YNuh5uPI/tDFSAUwLnYOuH8LAY=; b=XPwWauCubxUbEtrc/8hBOZkIvucPwLNp/Xq2JLN4pCb7P/uEVoiJHJyk7jAfBV1Mpn cP4/FchTlh8nNvjJ6+mRw+Ef415YTFBItYju8C+VfG0lMfNTlxl0uqnjuYteXw0Y/PMR a92qS+jaSPvio/qtvkg6QAQy/sS3EaMh4UaGdFW4KYvEiU2XM1+VBjj1ij1SHdUX8por tpaLZuWH8vbw7l/wyHVkqAQx+kTuQLuWIT9VOD5kG3KByy3fVt1FVCOy3JoSqCIYhouR 89IgseALgmYKzTUJ/ZwQgKsZ4CbNYHeg2lIfmKbhAsEp7+60XcxVvSS62JQSZQtZ5iNx onaw==
X-Gm-Message-State: AEkoouuhL7B9Euwht7FTm2HjYORYj64rWW4UsefBQiqPG/4NnYTJ7KDL/MEDJStwi7WqBLPY6ayeD3zYi9fj3NwF
X-Received: by with SMTP id p26mr8685541lfg.122.1469485959241; Mon, 25 Jul 2016 15:32:39 -0700 (PDT)
MIME-Version: 1.0
From: David Benjamin <davidben@chromium.org>
Date: Mon, 25 Jul 2016 22:32:29 +0000
Message-ID: <CAF8qwaCaW2Q+z_JoDqzQZaGCWJ2aqUiyK8_J8_CO4Ck_cqtaSA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a114024a49ab17c05387d5c58
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kYvjCabH98Fdy-GHK17jj34iOuI>
Subject: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 25 Jul 2016 22:32:46 -0000

Hi folks,

I'm not sure how this process usually works, but I would like to reserve a
bunch of values in the TLS registries to as part of an idea to keep our
extension points working. Here's an I-D:

(The name GREASE is in honor of AGL's rusted vs. well-oiled joints analogy
from https://www.imperialviolet.org/2016/05/16/agility.html )

One problem we repeatedly run into is servers failing to implement TLS's
various extension points correctly. The most obvious being version
intolerance. When we deployed X25519 in Chrome, we discovered an intolerant
implementation. (Thankfully it was rare enough to not warrant a fallback or
revert!) It appears that signature algorithms maybe also be gathering rust.
Ciphers and extensions seem to have held up, but I would like to ensure
they stay that way.

The root problem here is these broken servers interoperate fine with
clients at the time they are deployed. It is only after new values get
defined do we notice, by which time it is too late.

I would like to fix this by reserving a few values in our registries so
that clients may advertise random ones and regularly exercise these
codepaths in servers. If enough of the client base does this, we can turn a
large class of tomorrow's interop failures into today's interop failures.
This is important because an bug will not thrive in the ecosystem if it
does not work against the current deployment.

If you were in Berlin, you may recognize this idea from the version
negotiation debate. Alas that all happened in the wrong order as I hadn't
written this up yet. This idea can't be applied to versioning without
giving up on ClientHello.version, but we can start with the rest of the


PS: This is actually my first I-D, so apologies if I've messed it up