Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Wed, 09 June 2010 05:22 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 514323A6885 for <tls@core3.amsl.com>; Tue, 8 Jun 2010 22:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.051
X-Spam-Level:
X-Spam-Status: No, score=-10.051 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 HfkpLYLi1TS2 for <tls@core3.amsl.com>; Tue, 8 Jun 2010 22:22:04 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2F6123A68C2 for <tls@ietf.org>; Tue, 8 Jun 2010 22:22:04 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAF/BDkyrR7Ht/2dsb2JhbACeRHGjVpoBhRYEg0c
X-IronPort-AV: E=Sophos;i="4.53,388,1272844800"; d="scan'208";a="541992370"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 09 Jun 2010 05:22:05 +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 o595M54r023281; Wed, 9 Jun 2010 05:22:05 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); Tue, 8 Jun 2010 22:22:05 -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: Tue, 08 Jun 2010 22:22:04 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50AA7E497@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <012d01cb071d$7ef013a0$4001a8c0@gateway.2wire.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
Thread-Index: AcsHJlvZOLJAE3vlSOKkb3ihAc96ewAa2QmQ
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> <AC1CFD94F59A264488DC2BEC3E890DE50AA7DE90@xmb-sjc-225.amer.cisco.com> <012d01cb071d$7ef013a0$4001a8c0@gateway.2wire.net>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: tls@ietf.org
X-OriginalArrivalTime: 09 Jun 2010 05:22:05.0671 (UTC) FILETIME=[B31B9F70:01CB0793]
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 05:22:05 -0000
We should revise the draft with the text below, and add NOT RECOMMENDED to section 1.2. When the revision is available we can have Sean continue progressing the document. "The ServerNameList MUST NOT contain more than one name of the same name_type. If the server understood the client hello extension, but decides not 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 understood the client hello extension, but 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 or sent during a TLS handshake. Such information can be useful for diagnostic purposes." > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Tuesday, June 08, 2010 5:45 AM > To: Joseph Salowey (jsalowey) > Cc: tls@ietf.org > Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert > > I was about to say that ... but eventually realised I was misinterpreting > the > text, so I suggest adding a clause to express the 'if-then-else' more > rigourously ie > > "The ServerNameList MUST NOT contain more than one name of the same > name_type. > > If the server understood the client hello extension, but > **decides not 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 understood the client hello extension but** decides to > continue > the handshake, sending a warning-level unrecognized_name(112) alert is > NOT > RECOMMENDED, since existing client behavior is unpredictable. > > ...." > > which also makes it clear we are not covering the case of client hello > extension > not understood. > > Tom Petch > > ----- Original Message ----- > From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com> > To: <mrex@sap.com> > Cc: <tls@ietf.org> > Sent: Tuesday, June 08, 2010 1:10 AM > Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert > > > > 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 mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls
- [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