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

Adam Langley <agl@imperialviolet.org> Thu, 03 March 2016 18:49 UTC

Return-Path: <alangley@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C19261B3BB5 for <tls@ietfa.amsl.com>; Thu, 3 Mar 2016 10:49:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.122
X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4aPwHyeEKKTT for <tls@ietfa.amsl.com>; Thu, 3 Mar 2016 10:49:38 -0800 (PST)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 D5DF61B40A0 for <tls@ietf.org>; Thu, 3 Mar 2016 10:49:37 -0800 (PST)
Received: by mail-qg0-x235.google.com with SMTP id y89so24499537qge.2 for <tls@ietf.org>; Thu, 03 Mar 2016 10:49:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to :content-transfer-encoding; bh=4JiKxCUvONUHO7SneWIvKoCDyCEFiVrZQ/j0+7r+Yhw=; b=uQetrsA+hlvxXbtCpuNDEj5z6hYz4Fx+Gnp5Rs1RZqcRwBVWjxNaKG6Z+NeArrbYCi awSpjRUoZcqds9Sgb9NdcvHaog69S23CSNtX0Ap/hQ2hnJBIM+8K0LTr0WjtJo/QPfRT Z7BnI1NXlQzITtgPW0rUweWFc1i+Jg4hRNe5ScizwFDS9HeAfrJcTDN0qS3L7aBRP77c CLdYyRkX52S126GUyndOaxnTYITKezyBRhEs0m6qI4IIW+ymBkvaE/ro9dJ7jE+2n8ET kz+PcJf2BDTc0vl4OTPJtJ/WF2kkgjz7LXhV6E1s1T1wvusFa3SGrnXuQhmSO/PYybqn 23oA==
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:date:message-id:subject:from :to:content-transfer-encoding; bh=4JiKxCUvONUHO7SneWIvKoCDyCEFiVrZQ/j0+7r+Yhw=; b=Xt61icPDPNSjmGa04nImnImAAwtXIUQekzyajOCY1lkH1u2WwYbuPpmekCWaYJ+k2I hqRFZZKjWjfj+cPh734i3qBN6Pk2ByaRNkcbHPH26G7wC+Jo/lcPPQAe24217zW1N3md 6GHhC3bFosvm8wP9R0TKyPOtHi2bsdCDmerevlQwRHKlBSricaIcakO/aVAlOkkGT9zG ag4k4vCnPy8jvzOhaP1NIkIluQLy69siVktQXMtQwyMELoeIMO4wz+lsSiZJcRKS02Ie X5qAD5SNXh8eZXYW+XDzKVivo60LWijZIp97cxS3n+JJwhuThGv6a60zH34ca48Ggdk4 3LPg==
X-Gm-Message-State: AD7BkJIW6st4S4U4tMcovymbogjV3U2k2DbHpS67jOFjqRyr2q4DcvsY/HsQ9zX/vTjivZQiweE/S6AuhaOsag==
MIME-Version: 1.0
X-Received: by with SMTP id c78mr4904747qge.101.1457030976960; Thu, 03 Mar 2016 10:49:36 -0800 (PST)
Sender: alangley@gmail.com
Received: by with HTTP; Thu, 3 Mar 2016 10:49:36 -0800 (PST)
Date: Thu, 3 Mar 2016 10:49:36 -0800
X-Google-Sender-Auth: Fu0HTJzBe3czvjy69W4vH8tE440
Message-ID: <CAMfhd9WNHqfRH=M=_B7_apJ-r43fi8qoe-+VcDkrKPwwhkPR5A@mail.gmail.com>
From: Adam Langley <agl@imperialviolet.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/1t79gzNItZd71DwwoaqcQQ_4Yxc>
Subject: [TLS] Accepting that other SNI name types will never work.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 03 Mar 2016 18:49:39 -0000

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



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