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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 09 March 2016 14:05 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 51D7B12D61C for <tls@ietfa.amsl.com>; Wed, 9 Mar 2016 06:05:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level:
X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 SDmBj6tSPAYA for <tls@ietfa.amsl.com>; Wed, 9 Mar 2016 06:05:43 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04E8E12DE60 for <tls@ietf.org>; Wed, 9 Mar 2016 06:05:36 -0800 (PST)
Received: from [192.168.10.140] ([195.149.223.22]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M5uLh-1ZtwoR0y3l-00xtKU; Wed, 09 Mar 2016 15:05:34 +0100
To: Adam Langley <agl@imperialviolet.org>, "tls@ietf.org" <tls@ietf.org>
References: <CAMfhd9WNHqfRH=M=_B7_apJ-r43fi8qoe-+VcDkrKPwwhkPR5A@mail.gmail.com>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <56E02DAB.1030104@gmx.net>
Date: Wed, 9 Mar 2016 15:05:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CAMfhd9WNHqfRH=M=_B7_apJ-r43fi8qoe-+VcDkrKPwwhkPR5A@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nplMOoTlACQcWbDfAKpeGmRQLwJsG1Js1"
X-Provags-ID: V03:K0:jXYZvviL2BasjyhhswBoYgHp+h/KTwzdg/oyNqPQ9h38syBMHwb K9yPhrQ6S6lJDCJJ4I3WhyG01vrYO7QPZeqWdCQv6rzFfefRWOmr5UadI1nHe6VSenv0Wg4 007K/3k+wMqpC0qWplvue/xLeeubLVQmjGSRqEeBqBU6R/SoGWs9aKamMO+pt09lC8/zWNt ez49157ujUInF9g/8vVLA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:x9BY9LgdeAw=:y6xC+smbRYD6jGwTukmc+W xvSL5yKB7I7HpcEKM2+fEmLXJlOG9t3Vr+z5IFqCW7fgpbIRw9UWI0uPtZpeMTR/L3zw2f64A h5S56F3F2zmFWrNwPOiTojSHRP+6OP5NqGZPlHVuOZweSs+lHeFhLXd5N/0rfwDHlDXALUL68 QeT5fMY3YM6VOe/F7fHkQQN1AOag24aTwl0OuHR2brZzEjZQZEx8VbKCeHgAo/g2CKm/Sbiu/ cduiujxBAPZWS5U3TfwLkzPCQp6UAuAbtnO0KDpl6V0wXZnGWCCwTvHdGAt8bO+Acy1PXY048 HPCjbftFooZmoGMO9aWqb7kyDQ+3CIA5Gd+qN328us8eW6oAZRNFWnc2vuVcNme3/URum4GA3 HZWoSpIuytI80myhQL2azfbgiEfIeH2azbWJzmUqrx60J7My1JAhe9gLCP++KXQYlmYa1iyAQ Y+uN0gd4guaSBWXF6N5mhZfWeXo+k7vzTe9Tu+oqf9uG8Q8NeK2KoOaWafhhuTbDNMa5ycqRa evkiVNSsje67vopLWECk41FfWYz82IeJXCcOMxXvQ1U7m1C/cBQRUsHs1yDYPTn1OdjYV+i4p jfLL7OtqlKsJ6nF874cFfhICb3b3cfp3pDb9GLLKckdXCHoFQsnyNjMpSxtsEiaTI3Svr3HN+ nHT+FnxxPRWOXO5Nh0LidhswBdXIntHsQHn0wiwwokz53m3HXF2AkLzzXjcOQsBoLd+CuI2po x0ZjMZCYGtOHqV8VK4rX5d+jm61yCgIIachctcda6ivdZe62SfjnFTseiZ8=
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/4PGmdo9udMUxD9ctg3E4Ki1V-JQ>
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 14:05:45 -0000

Hi Adam,

as Thomas mentioned in his email we are looking into extending the SNI
functionality.

Let me explain why we are doing it.

We are focused on Internet of Things deployments and we want to use
TLS/DTLS there to provide communication security. The use of TLS/DTLS
would solve some of the problems we see in deployments today where
either no communication security is used (such as in the BMW Connected
Drive example) or where custom security solutions are used. We want to
make it easy for developers to add commonly used security services to
their applications.

Everything fine so far.

In many deployments the IoT device acts as a client and initiates the
connection to some cloud-based infrastructure (or to some gateway). In
other deployments the IoT device needs to act as a server. In fact, in
many home network/small enterprise deployments this seems to be the
envisioned model.

Assuming that every IoT device has a domain name is not desired or
useful. Instead, the CORE working group has developed the so-called
Resource Directory, which acts as a rendezvous point, and may even have
more capabilities -- with extensions, like caching of data, while the
IoT devices sleeps. ("Sleeping devices" consume less energy.)

Now, we had to come up with another story of what information to put
into certificates or, alternatively, forget the use of certificates.

I know that the timing isn't necessarily in our favor. You guys are
trying to move the TLS 1.3 spec along and our contribution is still
subject to (longer) discussion at the CORE working group. I also
understand that you may not necessarily be super interested in IoT usage
either.

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 believe other organizations who are also looking into these types of
IoT scenarios will sooner or later also figure out that there is a problem.

Ciao
Hannes


On 03/03/2016 07:49 PM, Adam Langley wrote:
> The Server Name Indication (SNI) extension in TLS has a provision to
> provide names other than host names[1]. None have even been defined to
> my knowledge, but it's there.
> 
> OpenSSL (and possibly others) have had a long-standing bug[2] (fixed
> in master) that means that different types of names will cause an
> error. To be clear: I live in a glass house and am not throwing
> stones; these things happen. However, it means that a huge fraction of
> the TLS deployment will not be able to accept a different name type
> should one ever be defined. (This issue might have been caused by the
> fact that the original[3] spec didn't define the extension in such a
> way that unknown name types could be skipped over.)
> 
> Therefore we (i.e. BoringSSL, and thus Google) are proposing to give
> up on this and implement our parser such that the SNI extension is
> only allowed to contain a single host name value. (This is compatible
> with all known clients.) We're assuming that since this is already the
> de-facto reality that there will be little objection. I'm sending this
> mostly to record the fact so that, if someone tries to define a new
> name type in the future, they won't waste their time.
> 
> If the community wishes to indicate a different type of name in the
> future, a new extension can be defined. This is already effectively
> the case because we wouldn't fight this level of incompatibility when
> there's any other option.
> 
> (I think the lesson here is that protocols should have a single joint,
> and that it should be kept well oiled. For TLS, that means that
> extensions should have minimal extensionality in themselves and that
> we should generally rely on the main extensions mechanism for these
> sorts of things.)
> 
> [1] https://tools.ietf.org/html/rfc6066#section-3
> [2] https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/ssl/t1_lib.c#L1066
> – note that the data pointer is not updated.
> [3] https://tools.ietf.org/html/rfc4366#section-3.1
> 
> 
> Cheers
> 
> AGL
>