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

[Hannes Tschofenig <[e-mail]>]

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
>