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

Sean Turner <> Tue, 08 June 2010 15:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E80D3A69C7 for <>; Tue, 8 Jun 2010 08:51:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4BTuSePbsws4 for <>; Tue, 8 Jun 2010 08:50:56 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id E39663A69C3 for <>; Tue, 8 Jun 2010 08:50:55 -0700 (PDT)
Received: (qmail 1795 invoked from network); 8 Jun 2010 15:50:54 -0000
Received: from thunderfish.local (turners@ with plain) by with SMTP; 08 Jun 2010 08:50:54 -0700 PDT
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: pSRiBPIVM1kFk8MaOaVkcnTd._3yNUQcLvvG_ryknrvfOoua2cGPRzcG_DPVPKugelmMPu0PW98iGYeAdr_aRcW8xONJVVhB42F..f4a9oOrJG7Lcc92OhKc_BhsqoC3d4ZwkPGk0Uh0yZ5lgYF74ewNI9zr3gQt6COdqbNnMsOABy_85632HAiTZIsoZH7qS7NzJx9vJjv13nxu4XwFeTut0TwIYymIveNzOcGX.i5YitHNA3rBIBMI6aBKQ_SPegkHtrNjsx2.yfLOQaatC8a1n2ln7m3t58lmDw5zvHEsb98p82d73xqDKidoiEse_tV_LvELkihDPmBzZe9V4ZEiI9OmWmJnbC9AddZO307Kq9o65IRoJmY95NH2dT2Mwk5pIjhGLvivCGmccmZqUf_.wPXlNVKn8jIyraR4sytjMMVPdokAv1R_NXzC8d_fhh7KjdP6G0dKVYnhKSEp6B_X
X-Yahoo-Newman-Property: ymail-3
Message-ID: <>
Date: Tue, 08 Jun 2010 11:50:54 -0400
From: Sean Turner <>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: "Joseph Salowey \(jsalowey\)" <>
References: <> from "Joseph Salowey" at Jun 7, 10 01:29:11 pm <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Tue, 08 Jun 2010 15:51:00 -0000

Nikos Mavrogiannopoulos wrote:
> Joseph Salowey (jsalowey) wrote:
>> OK with me, so we have:
>> "The ServerNameList MUST NOT contain more than one name of the same
>> name_type. If the server understood the client hello extension, but
>> refuses to continue because it does not recognize the server name, it
>> MUST send a fatal unrecognized_name(112) alert and terminate the
>> handshake.  If the server decides to continue the  handshake, sending a
>> warning-level unrecognized_name(112) alert is NOT RECOMMENDED, since
>> existing  client behavior is unpredictable. A TLS client implementation
>> that receives a warning-level unrecognized_name(112) alert SHOULD ignore
>> this alert and continue the TLS handshake.  If there is a mismatch
>> between the server name used by the client application and the server
>> name of the default credential chosen by the server, this mismatch will
>> become apparent when the client application performs the server endpoint
>> identification, at which point the client application will have to
>> decide whether to proceed with the communication.  TLS implementations
>> are encouraged to make information available to application callers
>> about warning-level alerts that were received during a TLS handshake.
>> Such information can be useful for diagnostic purposes. "
> It is ok with me. My only reservation would be "... sending a
> warning-level unrecognized_name(112) alert is NOT RECOMMENDED ...". One
> might deduce, ok let's send some other alert to indicate the situation.
> I'd prefer "... sending any warning-level alert to indicate this
> situation is NOT RECOMMENDED ..."

If you're going to use "NOT RECOMMENDED" add it to section 1.2.  You 
could use something like*:

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
  "MAY", and "OPTIONAL" in this document are to be interpreted as
  described in [RFC2119].