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

Eric Rescorla <> Thu, 03 March 2016 18:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 921511B40BA for <>; Thu, 3 Mar 2016 10:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dS5AQqr7U44u for <>; Thu, 3 Mar 2016 10:57:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F4C91B2CBA for <>; Thu, 3 Mar 2016 10:57:11 -0800 (PST)
Received: by with SMTP id b72so22928734ywe.0 for <>; Thu, 03 Mar 2016 10:57:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kyiuNvL4Qufyt+VuRMOfP648EzFipWJkkarB3szRI2Q=; b=pnBgsIpm0ES0lObOqVgXB+/wpQVyA8sUBG/6H+2R37tauotnGoeQg45MTJsJf0FAMb Ud+hR5Mji/XNUSAcTRF6xowsgaGGBVlSezhcsZRMmRi/8x8KtoyIlN2Ou/DaGMHcr+OP iUSHwQy8OKnwUwRkmII+UxDBT7n4yWNbR67gULr/K10SSCT9YnRGQty5ktfj2i3kAnT4 rYZbnw67PNyU3K55DoOPlUmmQsvpiL6z9HLl7o7DRB576eoyfFZf46mc25ZhWAl654Bo Jch+Ma6zTsw5hLMrGG7r52ddSMJDAEIW/HQzKxreeclIr/au7SaKqerOWXA/G+wkkkf8 PVqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kyiuNvL4Qufyt+VuRMOfP648EzFipWJkkarB3szRI2Q=; b=RmR8hfM3WuCpnW21O9in6s/LPCVEq8gD5efu+uWVb4IxvfNY5dG2B4oI3MSGxcVMbx YKyblGVzGeJXrCzG2wjBQ9n6je5WV8y5wU/8pStWPMfAJN/mF+qnlgbOy80Tgac0bEVl wXdBktKixn6F9zxYPpkTZVh80RAzDflkrp3EY2OmkZwODG7A3WUToC5X1Dr4cJg4x37K CDMmrRxc2sQJk2gXKUJHUVmSN81JX3jvkMU10gfEP0sSy13PTu87aQMN97xnSkkiRD75 jli39EnbjWRLC+IFihZXQX3/2RYvU2mgTCLAQqWTTD1dAhNbuBLqkUBwx3d/tiOS7o8N 2WFQ==
X-Gm-Message-State: AD7BkJIUfprF2+PMs+6uYS7Upo6SJAbl+mOMCQ0Sa3UTnlgHOFQ0crFryb/3+S+iUOFnW5Nox1thGneyC6ytXQ==
X-Received: by with SMTP id w198mr2523265ywa.223.1457031430640; Thu, 03 Mar 2016 10:57:10 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 3 Mar 2016 10:56:31 -0800 (PST)
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Thu, 3 Mar 2016 10:56:31 -0800
Message-ID: <>
To: Adam Langley <>
Content-Type: multipart/alternative; boundary=001a114dc91cd9c5a4052d29907f
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Accepting that other SNI name types will never work.
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Mar 2016 18:57:12 -0000

On Thu, Mar 3, 2016 at 10:49 AM, Adam Langley <>

> 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.

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.