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

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Mon, 07 June 2010 23:10 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 74DC93A6816 for <tls@core3.amsl.com>; Mon, 7 Jun 2010 16:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.227
X-Spam-Level:
X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 ADXVGj1XApnm for <tls@core3.amsl.com>; Mon, 7 Jun 2010 16:10:36 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id D59DC3A6887 for <tls@ietf.org>; Mon, 7 Jun 2010 16:10:36 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEACcZDUyrR7Ht/2dsb2JhbACeKXGlcZo1hRcEg0o
X-IronPort-AV: E=Sophos;i="4.53,380,1272844800"; d="scan'208";a="140757388"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2010 23:10:37 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o57NAbRF011186; Mon, 7 Jun 2010 23:10:37 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jun 2010 16:10:37 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 07 Jun 2010 16:10:36 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50AA7DE90@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <201006072203.o57M3xeo025635@fs4113.wdf.sap.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
Thread-Index: AcsGjWNITACMWKDJTbStosjX/U+geQACHIAA
References: <AC1CFD94F59A264488DC2BEC3E890DE50AA7DD71@xmb-sjc-225.amer.cisco.com> from "Joseph Salowey" at Jun 7, 10 01:29:11 pm <201006072203.o57M3xeo025635@fs4113.wdf.sap.corp>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: mrex@sap.com
X-OriginalArrivalTime: 07 Jun 2010 23:10:37.0799 (UTC) FILETIME=[A4167F70:01CB0696]
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: Mon, 07 Jun 2010 23:10:40 -0000

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. "



> -----Original Message-----
> From: Martin Rex [mailto:mrex@sap.com]
> Sent: Monday, June 07, 2010 3:04 PM
> To: Joseph Salowey (jsalowey)
> Cc: tls@ietf.org
> Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
> 
> Joseph Salowey wrote:
> >
> > OK, here is some new suggested text.  Let me know if you can live
with
> > this.
> >
> > "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
> > unrecognized_name(112) alert with a warning level is NOT
RECOMMENDED,
> > since existing  client behavior is unpredictable.  A client that
> > receives a warning-level unrecognized_name(112) alert SHOULD ignore
this
> > alert and continue the TLS handshake, which may fail as a result of
a
> > name mismatch.  The warning MAY be logged as part of diagnostic
> > information recorded for a failed handshake."
> 
> 
> I am fine with what I think is the intention of this wording,
> but I would actually appreciate to be more specific about what
> "may fail as a result of a name mismatch" applies to exactly.
> 
>                                                      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 wether 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.
> 
> 
> -Martin