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
- [TLS] RFC-4366-bis and the unrecognized_name(112)… Yngve Nysaeter Pettersen
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Nikos Mavrogiannopoulos
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Yngve Nysaeter Pettersen
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Nikos Mavrogiannopoulos
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Yngve Nysaeter Pettersen
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Marsh Ray
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Marsh Ray
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Peter Saint-Andre
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- [TLS] [Fwd: Re: RFC-4366-bis and the unrecognized… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Marsh Ray
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Nikos Mavrogiannopoulos
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Nikos Mavrogiannopoulos
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Peter Gutmann
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Nikos Mavrogiannopoulos
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Donald Eastlake
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Sean Turner
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… t.petch
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Paul Hoffman
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Marsh Ray
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Peter Saint-Andre
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Marsh Ray
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Nikos Mavrogiannopoulos
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Peter Sylvester
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Peter Sylvester
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Peter Sylvester
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex