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

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 09 June 2010 16:38 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4E5428C101 for <tls@core3.amsl.com>; Wed, 9 Jun 2010 09:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.992
X-Spam-Level:
X-Spam-Status: No, score=0.992 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vwxe1PMKCD-X for <tls@core3.amsl.com>; Wed, 9 Jun 2010 09:38:12 -0700 (PDT)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 60E373A6858 for <tls@ietf.org>; Wed, 9 Jun 2010 09:38:12 -0700 (PDT)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o59GcBvO083022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jun 2010 09:38:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p0624083bc83572582a36@[10.20.30.158]>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE50AA7E552@xmb-sjc-225.amer.cisco.com>
References: <4C0FA538.7050309@pobox.com> from "Michael D'Errico" at Jun 9, 10 07:29:12 am <201006091456.o59EukJ3015376@fs4113.wdf.sap.corp> <AC1CFD94F59A264488DC2BEC3E890DE50AA7E552@xmb-sjc-225.amer.cisco.com>
Date: Wed, 9 Jun 2010 09:37:54 -0700
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: tls@ietf.org
Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
X-BeenThere: tls@ietf.org
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." <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: Wed, 09 Jun 2010 16:38:13 -0000

At 8:12 AM -0700 6/9/10, Joseph Salowey (jsalowey) wrote:
>Thanks, 
>
>The text below looks much better looks much better. Let's go with that.
>
> >  "The ServerNameList MUST NOT contain more than one name of the same
>>   name_type.  If the server understood the client hello extension,
>>
>>   but does not recognize the server name, the server has two options.
>>   Either abort the handshake sending a fatal unrecognized_name(112)
>>   alert or continue the handshake using a default credential.
>>   Sending a warning-level unrecognized_name(112) alert in the latter
>>   case is NOT RECOMMENDED, since existing client behaviour is
> >   unpredictable.

This is definitely more understandable than earlier revs. However, there is still not enough definitive wording. I propose:

The ServerNameList MUST NOT contain more than one name of the same
name_type.  If the server understood the ClientHello extension but
does not recognize the server name, the server SHOULD take one of two
actions: abort the handshake by sending a fatal
unrecognized_name(112) alert, or continue the handshake using a
default credential. Sending a warning-level alert such as
unrecognized_name(112), but continuing the handshake, is NOT
RECOMMENDED because the client's expected behavior in response to
this is unpredictable.

--Paul Hoffman, Director
--VPN Consortium