Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert

Michael D'Errico <> Fri, 11 June 2010 22:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71DD128C0F8 for <>; Fri, 11 Jun 2010 15:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.522
X-Spam-Status: No, score=-0.522 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Dv45kmZSHMbq for <>; Fri, 11 Jun 2010 15:48:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DCD8D28C115 for <>; Fri, 11 Jun 2010 15:48:00 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 3AE5DBBAA6; Fri, 11 Jun 2010 18:48:02 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=KiiXoNf/R63h XBJXq5vAIoKjTT8=; b=cH9hVrAxrlCBIM/sFG5c+LuOqwlOy7CED6YFToGgmatk i/iK9OnS1ABP/xTT5UehAKVltjdU7T3kM2DCQbylRoaXo5FT9uQcswNEEjs3TbSC prn/pJdIR0tTj9OoBcy+wfDKGbQ9PCegFt/ZaC+KIPikvDz7uqZWp/JaITlcyp0=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=D9whZX Oganio8rw+FE/+XfRXSpO4iBvCvdQQ/0X7+pqQtuMn9sj69hRrM9kZPlfESHmUv8 3IpfzHeKRhD0PstficLmx2Blki/RJUXgo6RoX5aHxeowoogtxbrwwG4QlHrqcssy bVFOLkK3yF7XLzuIRWXHOidkz2kVDgTslC+lA=
Received: from a-pb-sasl-quonix. (unknown []) by (Postfix) with ESMTP id 52684BBAA5; Fri, 11 Jun 2010 18:48:00 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id EF7CBBBAA4; Fri, 11 Jun 2010 18:47:47 -0400 (EDT)
Message-ID: <>
Date: Fri, 11 Jun 2010 15:47:46 -0700
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20090812)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 62DE3EB0-75AB-11DF-A7BE-9056EE7EF46B-38729857!
Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
X-Mailman-Version: 2.1.9
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: Fri, 11 Jun 2010 22:48:02 -0000

Martin Rex wrote:
> SNI is _not_ a naming service.  It is not even a part of TLS itself.

I have no idea what point you're trying to make here.  What gives you
the idea that the server name extension is not a part of TLS?  It was
a missing requirement that has been added as an extension, which is
similar to the "Host:" header of HTTP.  "Host:" was not a part of the
first HTTP specification, but its need became clear and it was added
later.  That does not mean that "Host:" is not actually a part of HTTP!

> SNI is a hint for the server application created by the client application
> and conveyed through a TLS extension.

No, it's not a "hint."  It tells the TLS layer which domain name the
client is trying to communicate with.  If you have a server that handles
more than one domain name on the same IP address, there is no other way
for the TLS layer to know which certificate chain to use in its negotia-

> RFC-5246 is pretty clear about this (last sentence of section 1):
>    the decisions on [...] how to interpret the authentication certificates
>    exchanged are left to the judgment of the designers and implementors
>    of protocols that run on top of TLS. 

Yes, but it was decided that RFC 5246 would not subsume RFC 4366 (TLS
extensions), so of course RFC 5246 does not say anything about SNI.

> So a TLS server implementation that makes bold assumptions about what
> fancy things it should do with the server_name in an incoming ClientHello
> is obviously broken.  This is an application-level issue, and a TLS
> server application should not do anything unless explicitly instructed
> to do so by the calling application.  A TLS server implementation that
> attempts to be "smart" without being directed by the server application
> is violating the TLS spec and can easily cause needless interop problems.

It's apparent that you don't understand what SNI is for.  TLS absolutely
needs to know which domain name a client is trying to connect to so that
an appropriate certificate chain can be selected.  The "Host:" header
fixed HTTP so that it could handle multiple domains on a single IP
address; that and the SNI extension fix HTTPS to work for multiple
domains on a single IP address.  Nothing fancy about it, and certainly
not broken.