[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.140.93.84 with SMTP id c78mr4904747qge.101.1457030976960; Thu, 03 Mar 2016 10:49:36 -0800 (PST)
Sender: alangley@gmail.com
Received: by 10.140.93.22 with HTTP; Thu, 3 Mar 2016 10:49:36 -0800 (PST)
Date: Thu, 03 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 Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
- Re: [TLS] Accepting that other SNI name types wil… Martin Thomson
- [TLS] Accepting that other SNI name types will ne… Adam Langley
- Re: [TLS] Accepting that other SNI name types wil… Eric Rescorla
- Re: [TLS] Accepting that other SNI name types wil… Adam Langley
- Re: [TLS] Accepting that other SNI name types wil… Salz, Rich
- Re: [TLS] Accepting that other SNI name types wil… Martin Thomson
- Re: [TLS] Accepting that other SNI name types wil… Richard Moore
- Re: [TLS] Accepting that other SNI name types wil… Martin Thomson
- Re: [TLS] Accepting that other SNI name types wil… Dave Garrett
- Re: [TLS] Accepting that other SNI name types wil… Martin Thomson
- Re: [TLS] Accepting that other SNI name types wil… Fossati, Thomas (Nokia - GB)
- Re: [TLS] Accepting that other SNI name types wil… Fossati, Thomas (Nokia - GB)
- Re: [TLS] Accepting that other SNI name types wil… Yuhong Bao
- Re: [TLS] Accepting that other SNI name types wil… Martin Thomson
- Re: [TLS] Accepting that other SNI name types wil… Fossati, Thomas (Nokia - GB)
- Re: [TLS] Accepting that other SNI name types wil… Fossati, Thomas (Nokia - GB)
- Re: [TLS] Accepting that other SNI name types wil… Richard Moore
- Re: [TLS] Accepting that other SNI name types wil… Hubert Kario
- Re: [TLS] Accepting that other SNI name types wil… Hubert Kario
- Re: [TLS] Accepting that other SNI name types wil… Hubert Kario
- Re: [TLS] Accepting that other SNI name types wil… Richard Moore
- Re: [TLS] Accepting that other SNI name types wil… Hannes Tschofenig
- Re: [TLS] Accepting that other SNI name types wil… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Accepting that other SNI name types wil… Adam Langley