Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
"t.petch" <ietfc@btconnect.com> Tue, 08 June 2010 16:19 UTC
Return-Path: <ietfc@btconnect.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 E04F928C176 for <tls@core3.amsl.com>; Tue, 8 Jun 2010 09:19:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level:
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044]
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 e0Q5kBWM1ze5 for <tls@core3.amsl.com>; Tue, 8 Jun 2010 09:19:23 -0700 (PDT)
Received: from c2bthomr14.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by core3.amsl.com (Postfix) with ESMTP id D871D3A6917 for <tls@ietf.org>; Tue, 8 Jun 2010 09:19:18 -0700 (PDT)
Received: from pc6 (host86-172-78-59.range86-172.btcentralplus.com [86.172.78.59]) by c2bthomr14.btconnect.com with SMTP id FND85685; Tue, 8 Jun 2010 17:19:16 +0100 (BST)
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4C0E6D84.008F, actions=tag
Message-ID: <012d01cb071d$7ef013a0$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
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>
Date: Tue, 08 Jun 2010 14:44:51 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com
X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0204.4C0E6D85.018C, ss=1, fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine
X-Junkmail-IWF: false
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: Tue, 08 Jun 2010 16:19:25 -0000
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