IETF Logo Mail Archive

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

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Wed, 09 June 2010 18:06 UTC

Return-Path: <jsalowey@cisco.com>
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 1249B3A67E7 for <tls@core3.amsl.com>; Wed, 9 Jun 2010 11:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.39
X-Spam-Level:
X-Spam-Status: No, score=-10.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 EgP7DpQLQY5D for <tls@core3.amsl.com>; Wed, 9 Jun 2010 11:06:42 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id ECB693A659A for <tls@ietf.org>; Wed, 9 Jun 2010 11:06:41 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAKp0D0yrRN+J/2dsb2JhbACDHppKaHGlNYkXkH+BJoMDbwSDSQ
X-IronPort-AV: E=Sophos;i="4.53,393,1272844800"; d="scan'208";a="209618837"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 09 Jun 2010 18:06:43 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o59I6hYI007862; Wed, 9 Jun 2010 18:06:43 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jun 2010 11:06:43 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Wed, 09 Jun 2010 11:06:42 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50AA7E6B2@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <4C0FCF4F.1060207@stpeter.im>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
Thread-Index: AcsH+T7g3+7FgWnZRAKcOGal1CAtowAA9kMw
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> <p0624083bc83572582a36@[10.20.30.158]><4C0FCC79.9010204@pobox.com> <4C0FCF4F.1060207@stpeter.im>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: Peter Saint-Andre <stpeter@stpeter.im>, tls@ietf.org
X-OriginalArrivalTime: 09 Jun 2010 18:06:43.0638 (UTC) FILETIME=[8481D560:01CB07FE]
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 18:06:49 -0000

Thanks all, I think we now have it:

"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: either abort the handshake by sending a fatal-level unrecognized_name(112) alert, or continue the handshake.  It is NOT RECOMMENDED to send a warning-level unrecognized_name(112) alert, because the client's behavior in response to warning-level alerts is unpredictable. If there is a mismatch between the server name used by the client application and the server name of the 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 or sent during a TLS handshake.  Such information can be useful for diagnostic purposes."

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
> Peter Saint-Andre
> Sent: Wednesday, June 09, 2010 10:29 AM
> To: tls@ietf.org
> Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
> 
> On 6/9/10 11:16 AM, Michael D'Errico wrote:
> > Paul Hoffman wrote:
> >>
> >> ... 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.
> >
> > The last sentence makes it unclear whether sending the alert is not
> > recommended or if continuing the handshake is not recommended.
> 
> Perhaps this is better:
> 
>    It is NOT RECOMMENDED to send a warning-level alert such as
>    unrecognized_name(112) but continue the handshake, because
>    the client's expected behavior in this case is unpredictable.
> 
> /psa
>

v2.23.0 | Report a Bug | By Email