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

Martin Rex <mrex@sap.com> Mon, 07 June 2010 22:04 UTC

Return-Path: <mrex@sap.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 0D9443A67D7 for <tls@core3.amsl.com>; Mon, 7 Jun 2010 15:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.02
X-Spam-Level:
X-Spam-Status: No, score=-8.02 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74, HELO_EQ_DE=0.35, 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 LUDfYbhlfTA2 for <tls@core3.amsl.com>; Mon, 7 Jun 2010 15:04:27 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E0C593A67A3 for <tls@ietf.org>; Mon, 7 Jun 2010 15:04:23 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o57M40qI016011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jun 2010 00:04:00 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201006072203.o57M3xeo025635@fs4113.wdf.sap.corp>
To: jsalowey@cisco.com (Joseph Salowey)
Date: Tue, 8 Jun 2010 00:03:59 +0200 (MEST)
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE50AA7DD71@xmb-sjc-225.amer.cisco.com> from "Joseph Salowey" at Jun 7, 10 01:29:11 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
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
Reply-To: mrex@sap.com
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 22:04:28 -0000

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