[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    [TLS] Accepting that other SNI name types will never work.
From:       Adam Langley <agl () imperialviolet ! org>
Date:       2016-03-03 18:49:36
Message-ID: CAMfhd9WNHqfRH=M=_B7_apJ-r43fi8qoe-+VcDkrKPwwhkPR5A () mail ! gmail ! com
[Download RAW message or body]

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 agl@imperialviolet.org https://www.imperialviolet.org


[prev in list] [next in list] [prev in thread] [next in thread]