Re: [TLS] Accepting that other SNI name types will never work.

Adam Langley <> Wed, 09 March 2016 16:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9502612E126 for <>; Wed, 9 Mar 2016 08:07:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Status: No, score=-2.35 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 57BwDKfBhVSg for <>; Wed, 9 Mar 2016 08:07:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09F6312DFB4 for <>; Wed, 9 Mar 2016 07:58:42 -0800 (PST)
Received: by with SMTP id t4so45113634qge.0 for <>; Wed, 09 Mar 2016 07:58:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=0UqMIpGZbIBB0w2RDbCWqsOcjFbM5BSmv/o0dH6yb5o=; b=Y7eCSEPcRqiTxL6U4LF6+4yw/wrQ1SBY9XNDm0EjFoli78FQ+pXaXaenSWIklFx/jJ TEBMiX3hLsEFhLXAoIEHVXKfoWudW7eknsw3SSx9vGfw+5Ojd6iy1TVXJyiIx9IMLTjJ SNqp0vdXGzbLEd4UyWz/Qww87etBO20LCp0owFe4zeLyaURst7r9nQT7P3ILhF0rJC5M upMPWs/wXqLDD3tv1VfB/hEPOzFR14D3mg3kHCsl2ZayzJdCWcHHyxF67QxVFCLapdNd 3zqCviB7TTRC9vHpoiI2G9rbGWGl77qGzPN23Pa4vUqwohdlgMGbX6EHvBTJ9UwnyGVW D1MA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=0UqMIpGZbIBB0w2RDbCWqsOcjFbM5BSmv/o0dH6yb5o=; b=g5RUVizG0c1cmyRCtkts/fYpkfSJzBTuErZnytjZuWgzQARPmWHGHk4NTiqEx9zts7 PQrIxcbapUA5KOVcFpilqyBrJ9wSSBPmjomorF81O+/lpun/YwRfRdLXk2Gfx+vzcdBo zxKi/OgIo2oy2yPrro6Y+TcmDqbuu0IwDIS80Y8iWs7B6i5ObIwpwF7CVfwE5FMqy+Ni NmGyE/tWuL3IwG9OS7opxCe40o7AkwDy/ukyHfop6HgPXUi2On7boEhA9AV/82/Nvbkw +jnH/O2uGIau8FZ+6XGSSEUTv2WvdgxzkaDGtwa2dnpMtybbXGVMR+17Myu/dwBl0dsy Lb0A==
X-Gm-Message-State: AD7BkJJMq3y9PTjWYMQOiQ4kvOHmGnwNFSqnp8UzQzCJrc2m2uyYe4k7BzgX0ZcN8JzemvpiKOngWlNeFuX7TA==
MIME-Version: 1.0
X-Received: by with SMTP id c78mr43552478qge.101.1457539119744; Wed, 09 Mar 2016 07:58:39 -0800 (PST)
Received: by with HTTP; Wed, 9 Mar 2016 07:58:39 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Wed, 9 Mar 2016 07:58:39 -0800
X-Google-Sender-Auth: 4vPZvWDziQPOeaUcZz7MZtnUbV4
Message-ID: <>
From: Adam Langley <>
To: Hannes Tschofenig <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Accepting that other SNI name types will never work.
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: Wed, 09 Mar 2016 16:07:25 -0000

On Wed, Mar 9, 2016 at 6:05 AM, Hannes Tschofenig
<> wrote:
> I still hope that this can be taken into consideration. I saw the
> proposal from Martin about defining another extension. This may be an
> option and maybe the answer is as simple as "don't use certificates for
> such scenarios".

I'm not sure that I understand your use-case enough to say anything
intelligent about it I'm afraid.

I'm just noting here that adding new SNI types is pretty bug-rusted.
Now, if you have a completely separate ecosystem you can solve the
deployment issues, of course. But I worry that if new SNI types are
added then, sooner or later, people will start to run into problems
with the current implementation ecosystem and a bunch of effort will
be wasted which could have been avoided by defining a new extension.
Therefore I recommend defining a new extension rather than a new SNI
type. Additionally, I'm suggesting that, in general, it's a good idea
to avoid nesting extension-like structures inside an extension in
favour of adding top-level extensions as needed.



Adam Langley