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

"Yngve Nysaeter Pettersen" <yngve@opera.com> Tue, 25 May 2010 13:43 UTC

Return-Path: <yngve@opera.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 540763A6B0C for <tls@core3.amsl.com>; Tue, 25 May 2010 06:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id Z6Y2IinweV73 for <tls@core3.amsl.com>; Tue, 25 May 2010 06:43:29 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com []) by core3.amsl.com (Postfix) with ESMTP id 89AA93A6BCF for <tls@ietf.org>; Tue, 25 May 2010 06:43:28 -0700 (PDT)
Received: from killashandra.oslo.osa (pat-tdc.opera.com []) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4PDhG5V002618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <tls@ietf.org>; Tue, 25 May 2010 13:43:17 GMT
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: tls@ietf.org
Date: Tue, 25 May 2010 15:42:42 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Yngve Nysaeter Pettersen" <yngve@opera.com>
Organization: Opera Software
Message-ID: <op.vc9kdggnvqd7e2@killashandra.oslo.osa>
User-Agent: Opera Mail/10.53 (Win32)
Subject: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: yngve@opera.com
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/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Tue, 25 May 2010 13:43:30 -0000

Hello all,

In the past few of weeks a couple of servers supporting SNI has come to my  
attention because they send the Warning alert "unrecognized_name" (112) in  
response to their actual name (that is, it should have recognized the  
name, and not sent that Warning).

It seems like these servers have started to use the SNI functionality in  
the underlying TLS implementation, but that there is a problem with  
configuring the handling of the extension and keeping it in sync with the  
rest of the configuration. That is a problem for the vendor.

RFC 4366-bis currently says:

    If the server understood the client hello extension but
    does not recognize any of the server names, it SHOULD send an
    unrecognized_name(112) alert (which MAY be fatal).

My question is: What should a client do if it receives this alert as a  

AFAICT there are several options:

   - Ignore it (several clients appears to do this currently). If so, what  
is the use-case for this warning?

   - Always ask the user. He or she probably won't understand the issue,  
and will click through anyway.

   - Check the certificate, and either warn the user if it does not match  
(which all browsers would do anyway without the alert; so why need the  
alert?), or escalate to Fatal.

   - Always escalate to Fatal (which is what Opera currently does)

What was the original reasoning for making the alert only optionally  
Fatal? Why not always Fatal, or always Warning?

May I suggest that the spec is updated with some advice for how a client  
should behave when it receives the alert as a Warning?

Yngve N. Pettersen
Senior Developer		     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01