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

From: Adam Langley <[email-masked]>
Date: Thu, 3 Mar 2016 10:49:36 -0800

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

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Mar 2016 10:56:31 -0800

> name type in the future, they won't waste their time.

Note: it's already the case that it's forbidden to send >1 of any given type
of name. NSS does not presently enforce this rule but will do so soon.

Regardless, I am in favor of this proposal.

-Ekr

---

From: Adam Langley <[email-masked]>
Date: Thu, 3 Mar 2016 11:01:59 -0800

> of name. NSS does not presently enforce this rule but will do so soon.

(We have enforced that for a while without issues.)

Cheers

AGL

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 3 Mar 2016 19:03:49 +0000

I’m in favor, wearing both OpenSSL and Akamai hats.

And wouldn’t it be a much kinder world if Adam wrote all posts on this list? ☺

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Mar 2016 09:44:23 +1100

> we should generally rely on the main extensions mechanism for these

Big +1

Note that the NSS bug also entailed non-zero SNI name types
overwriting the actual SNI.

---

From: Richard Moore <[email-masked]>
Date: Thu, 3 Mar 2016 22:52:36 +0000

If you're fixing that then maybe standardising the errors makes sense too.
My fingerprinter sees the following:

For an empty name:

SNIEmptyName: *(301)alert:DecodeError:fatal|
SNIEmptyName: *(301)alert:HandshakeFailure:fatal|
SNIEmptyName: *(301)alert:IllegalParameter:fatal|
SNIEmptyName: *(303)alert:UnexpectedMesage:fatal|
SNIEmptyName: error:Unexpected EOF receiving record header - server closed
connection|

For a long name (x repeated 500 times):

SNILongName: *(301)alert:HandshakeFailure:fatal|
SNILongName: *(301)alert:IllegalParameter:fatal|
SNILongName: *(301)alert:UnrecognizedName:fatal|
SNILongName: *(303)alert:UnexpectedMesage:fatal|
SNILongName: error:Unexpected EOF receiving record header - server closed
connection|

Rich.

On 3 March 2016 at 22:44, Martin Thomson <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Mar 2016 10:16:25 +1100

If we actually have a volunteer for sni-bis, then that would be OK with me.

However, I don't regard the errors as important.  Any hope that they
might be used in some automated fashion died a long time ago.  Mainly
due to this complete lack of consistency.  I assume that the last
error indicates that you didn't get an alert, which I find is
alarmingly common in TLS.

---

From: Dave Garrett <[email-masked]>
Date: Thu, 3 Mar 2016 20:43:42 -0500

Do we want to stick some simple new constraints on SNI in the TLS 1.3 draft spec? e.g. SHOULD have exactly one host_name which SHOULD be less than N bytes (significantly less than the current theoretical 64kB ceiling). Just adding a quick blurb for this in there somewhere seems like the simplest solution to me.

Dave

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Mar 2016 17:14:41 +1100

On 4 March 2016 at 12:43, Dave Garrett <[email-masked]> wrote:
> Just adding a quick blurb for this in there somewhere seems like the simplest solution to me.

That doesn't fix it for 1.2, but I'd be OK with that.  Define SNI as:

struct {
  uint16 extension_tag = 0;
  uint16 extension_length = strlen(name) + 5;
  uint16 name_list_length = strlen(name) + 3;
  uint8 name_type = 0;
  uint16 name_length = strlen(name);
  uint8 name[strlen(name)];
} SNI;

Or something like that.

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 4 Mar 2016 07:06:09 +0000

Hi Adam,

On 03/03/2016 18:49, "TLS on behalf of Adam Langley" <[email-masked]
on behalf of [email-masked]> wrote:
>[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.

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 4 Mar 2016 07:10:06 +0000

Trying again...

> Hi Adam,

In CoRE we might need to allocate a new SNI NameType for non-DNS host
names [1].

Removing SNI extensibility would make it unfeasible.

Cheers, t

[1] 
https://tools.ietf.org/html/draft-fossati-core-certmode-rd-names-00#section
-3.3

---

From: Yuhong Bao <[email-masked]>
Date: Thu, 3 Mar 2016 23:58:05 -0800

----------------------------------------
> From: [email-masked]
> To: [email-masked]; [email-masked]
> Date: Fri, 4 Mar 2016 07:10:06 +0000
> Subject: Re: [TLS] Accepting that other SNI name types will never work.
>
> Trying again...
>
>> Hi Adam,
>
>
Is limiting the list to only one SNI name entry feasible?

Yuhong Bao

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Mar 2016 19:42:46 +1100

> Removing SNI extensibility would make it unfeasible.

Not at all.  Define a new extension.  We have evidence that that works.

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 4 Mar 2016 09:03:41 +0000

Yes, I think so.

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 4 Mar 2016 09:03:53 +0000

On 04/03/2016 08:42, "TLS on behalf of Martin Thomson"
<[email-masked] on behalf of [email-masked]> wrote:

>Not at all.

It would, the way it is formulated at the moment.  But that doesn't
matter, we can change it to whatever as long as we can make it work.

>Define a new extension.  We have evidence that that works.

That can be done, of course.  Although it strikes me as odd to add another
extension given the exact same facility is already in place.

There are various ways SNI can be tightened other than removing the
parametrisation on NameType, e.g. limiting the number of ServerName
entries to 1.

---

From: Richard Moore <[email-masked]>
Date: Fri, 4 Mar 2016 15:42:29 +0000

On 3 March 2016 at 23:16, Martin Thomson <[email-masked]> wrote
​:​

> I assume that the last
​Yes, that's right.

Cheers

Rich.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 07 Mar 2016 13:00:54 +0100

On Thursday 03 March 2016 20:43:42 Dave Garrett wrote:
> Do we want to stick some simple new constraints on SNI in the TLS 1.3
> draft spec? e.g. SHOULD have exactly one host_name which SHOULD be
> less than N bytes (significantly less than the current theoretical
> 64kB ceiling). Just adding a quick blurb for this in there somewhere
> seems like the simplest solution to me.

The standard says that it must be a valid domain name, and those are 
IIRC limited to 255 characters.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Hubert Kario <[email-masked]>
Date: Mon, 07 Mar 2016 13:02:45 +0100

> alarmingly common in TLS.

well, if some people don't care about their implementation being 
fingerprintable, let them be, but there should but at least a 
recommendation what to do if you want to avoid that.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Martin Thomson <[email-masked]>
Date: Mon, 7 Mar 2016 23:32:55 +1100

> recommendation what to do if you want to avoid that.

I'd be very surprised if this added anything to the fingerprinting
entropy already present in TLS implementations.  You can't use this
sort of thing to distinguish one user of NSS from another NSS user.

BTW, I'm pretty much not willing to volunteer to review the patch that
made NSS less fingerprintable as NSS.  I'm pretty sure that involves
replacing NSS with OpenSSL.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 07 Mar 2016 13:41:44 +0100

> sort of thing to distinguish one user of NSS from another NSS user.

correct, but that's not what I meant by fingerprinting

> replacing NSS with OpenSSL.

the current fingerprinting depends on alert descriptions sent for 
different invalid messages

in most cases it's just a question of changing a decode_error to 
illegal_parameter or similar simple changes

---

From: Richard Moore <[email-masked]>
Date: Tue, 8 Mar 2016 19:55:58 +0000

> sort of thing to distinguish one user of NSS from another NSS user.
​No, but you can use this sort of thing in combination to determine the
version a server is running not just the implementation. If there was a
recommended alert for a given situation I imagine (perhaps over
optimistically) that it would be harder.

> replacing NSS with OpenSSL.

​Making it hard (or at least harder) to distinguish the two would
definitely not involve that. That said, I haven't fingerprinted NSS as a
server in anywhere near as many configurations as openssl though this is
mainly because I see it used that way less frequently.

Cheers

Rich.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 9 Mar 2016 15:05:31 +0100

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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 9 Mar 2016 15:37:00 +0000

Based on your explanation, the best solution architecture would be based
on *attribute* certificates (individual attributes signed independently by
their corresponding Attribute Authorities), rather than the current
“all-crammed-in” certificates.

The downside of the above is that this approach isn’t wide-spread, and
would be computationally more expensive (the need to potentially verify at
least two attributes, possibly more - instead of just dealing with one
signature that covers everything).
-- 
Regards,
Uri Blumenthal

On 3/9/16, 9:05 , "TLS on behalf of Hannes Tschofenig"
<[email-masked] on behalf of [email-masked]> wrote:

>>https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/ssl/t1_lib.c
>>#L1066

---

From: Adam Langley <[email-masked]>
Date: Wed, 9 Mar 2016 07:58:39 -0800

> option and maybe the answer is as simple as "don't use certificates for

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