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

"Yngve Nysaeter Pettersen" <> Fri, 04 June 2010 16:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43BCE3A69B9 for <>; Fri, 4 Jun 2010 09:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nuM2HnahNZiR for <>; Fri, 4 Jun 2010 09:00:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3B2BF3A67AD for <>; Fri, 4 Jun 2010 09:00:27 -0700 (PDT)
Received: from killashandra.oslo.osa ( []) by (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o54FxQWc031474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Jun 2010 15:59:37 GMT
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Nikos Mavrogiannopoulos" <>, "Joseph Salowey (jsalowey)" <>
References: <> <> <> <> <> <op.vdqdftkkvqd7e2@killashandra.oslo.osa> <>
Date: Fri, 04 Jun 2010 17:59:24 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Yngve Nysaeter Pettersen" <>
Organization: Opera Software
Message-ID: <op.vdr9damivqd7e2@killashandra.oslo.osa>
In-Reply-To: <>
User-Agent: Opera Mail/10.53 (Win32)
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, 04 Jun 2010 16:00:29 -0000

On Fri, 04 Jun 2010 08:38:33 +0200, Joseph Salowey (jsalowey)  
<> wrote:

> Hi Yngve,
> Thanks for the text, some questions below:
>> -----Original Message-----

> [Joe] It seems we still have the same problem, this just replaces the
> warning with a lack of empty server_name extension.  I'm not sure I see
> what this gains.  It also doesn't seem appropriate in this case to
> mandate a change in behavior on the server.  It seems that the server
> should return a server_name extension if it understands the extension
> (its implemented and enabled).

I think the questions that needs answering are "What does this extension  
and alert mean?" and "What do we want the client to do when it receives  
the alert?" (A thought: Are there other extensions and warning alerts that  
suffer from the same problem?)

The problem is that most warnings are not very useful to client, as  
mentioned in your quote from 5246, and most alerts are fatal anayway. This  
is part of the background for why I separated out the handful of warning  
we can handle automatically, and handled all other as fatal.

Regarding the extension what to do depends on what the extension from the  
server means. Is it "I support the extension" or "I recognized the name"?  
In the latter case it could be used to decide what to do if the presented  
certificate does not match the hostname (In which case the question  
becomes whether or not to throw a fatal alert, or present a warning to the  

> Maybe we should change the second paragraph text to
> "If the server understood the client hello extension but does not
>  recognize the server name, and it refuses to continue it MUST
>  send a fatal "unrecognized_name" alert.  If the server continues the
>  handshake, sending a "unrecognized_name"
>  alert with a warning level is NOT RECOMMENDED, since the
>  client behavior is unpredictable.  Some clients
>  may respond by aborting the handshake while others may allow it
>  to continue to certificate validation, which may fail as a result
>  of a name mismatch. "

Looks acceptable to me.

Yngve N. Pettersen
Senior Developer		     Email:
Opera Software ASA         
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01