Re: [TLS] Keeping TLS extension points working

David Benjamin <> Tue, 26 July 2016 11:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE19012D1C0 for <>; Tue, 26 Jul 2016 04:03:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BVj4ny0Nue6I for <>; Tue, 26 Jul 2016 04:03:52 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2ACEE12D0F5 for <>; Tue, 26 Jul 2016 04:03:52 -0700 (PDT)
Received: by with SMTP id b199so2487941lfe.0 for <>; Tue, 26 Jul 2016 04:03:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5a6310U9MZhQcaX9ACFYK2iM2A1K2VkMN2iYU6WSvBs=; b=eZi6A3GLNEMfy8bZdUtEGJvs+IGIJZQTJkQ4qwxtkMAg6YZda2lrSTTJfIggdR2LlX qDi9vJDu5DGbvgq/1nK6bwpCpGtPgUwxmGGl0X25Ef2XiP7eHGTmXAo4StSmFrSAYLGQ EQ5Cc2oorWjii1Vo8OQ0jPkL0AtzKMNWkZOOw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=5a6310U9MZhQcaX9ACFYK2iM2A1K2VkMN2iYU6WSvBs=; b=Ryp4wxbmdviayvPkgS8r3R8I0S2hrNQLIOFQ3gX20SzaIvEsbRzQG+JIgA7mGt5wSc MKIFdEGaoXpEjstd3GMhGkNEuTQvJ9HqbTusywS7UEzlg2MhiTdwsWqZuOfqq7ZZNVfT +CMNjx/C5+CLPiCyn0sElb7BRkMnfk9veWgQ+DCJzySZtGiUZVdrani+CMrg9ru4HflF f5fX8AhObA4EPNkf5CgOvFOJos+yILx2MZZ4xC4MJfkI6RaKxTg6890UpZep5SPyXB6f z+XNP/ThNRZNBV0CD3y3NbBmrFqIgvjLh3+9lX/hzpLcp4aWEbp9wQ+BdTkYSNcoos9/ AJzg==
X-Gm-Message-State: AEkoousL5oD0XySW+tqI7l+9tSyev4RCmRAvkN7LPpPv5V7b1M/Ze0d4SlcLAoa8iBJJShG3ZlkmXBoOTpwfGmic
X-Received: by with SMTP id r203mr10390373lfe.85.1469531030192; Tue, 26 Jul 2016 04:03:50 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Tue, 26 Jul 2016 11:03:39 +0000
Message-ID: <>
To: Hubert Kario <>,
Content-Type: multipart/alternative; boundary=001a114032a20ae32b053887db1e
Archived-At: <>
Subject: Re: [TLS] Keeping TLS extension points working
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Jul 2016 11:03:54 -0000

On Tue, Jul 26, 2016 at 6:56 AM Hubert Kario <> wrote:

> On Monday, 25 July 2016 22:32:29 CEST David Benjamin wrote:
> > 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.
> What prevents an implementation from ignoring values from just those
> reserved
> ranges and continuing to be intolerant to other values? After all, if they
> are
> reserved for this, they just need to ignore those values (as no "real"
> extension/value will ever use them) to "resolve the problem".

Nothing. Just as nothing prevents an implementation from taking every
ClientHello current browsers send (variable parts like client_random
normalized), hard-coding their SHA-256 hashes, and rejecting anything that
doesn't match.

The point is to catch honest mistakes, not to avoid servers that are
maliciously trying to mess up the ecosystem.

We can certainly increase the pool over time as Viktor suggested if
special-casing these becomes a problem. I don't expect it to be, but we'll
see. Whereas not ignoring unknown values has empirically been a problem.