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