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

Adam Langley <agl@imperialviolet.org> Wed, 09 March 2016 16:07 UTC

Return-Path: <alangley@gmail.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 9502612E126 for <tls@ietfa.amsl.com>; Wed, 9 Mar 2016 08:07:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57BwDKfBhVSg for <tls@ietfa.amsl.com>; Wed, 9 Mar 2016 08:07:24 -0800 (PST)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (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 09F6312DFB4 for <tls@ietf.org>; Wed, 9 Mar 2016 07:58:42 -0800 (PST)
Received: by mail-qg0-x22f.google.com with SMTP id t4so45113634qge.0 for <tls@ietf.org>; Wed, 09 Mar 2016 07:58:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.140.93.84 with SMTP id c78mr43552478qge.101.1457539119744; Wed, 09 Mar 2016 07:58:39 -0800 (PST)
Sender: alangley@gmail.com
Received: by 10.140.93.50 with HTTP; Wed, 9 Mar 2016 07:58:39 -0800 (PST)
In-Reply-To: <56E02DAB.1030104@gmx.net>
References: <CAMfhd9WNHqfRH=M=_B7_apJ-r43fi8qoe-+VcDkrKPwwhkPR5A@mail.gmail.com> <56E02DAB.1030104@gmx.net>
Date: Wed, 9 Mar 2016 07:58:39 -0800
X-Google-Sender-Auth: 4vPZvWDziQPOeaUcZz7MZtnUbV4
Message-ID: <CAMfhd9XvPUeypUQho+e6LA1iROvZaA-chVGSh2q6zFpLpbXRQQ@mail.gmail.com>
From: Adam Langley <agl@imperialviolet.org>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/U_A3pJZ2clmPGQimFcUqjSQo7uw>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Accepting that other SNI name types will never work.
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: Wed, 09 Mar 2016 16:07:25 -0000

On Wed, Mar 9, 2016 at 6:05 AM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> 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.


Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org