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

Sean Turner <turners@ieca.com> Tue, 08 June 2010 15:51 UTC

Return-Path: <turners@ieca.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 8E80D3A69C7 for <tls@core3.amsl.com>; Tue, 8 Jun 2010 08:51:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
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 4BTuSePbsws4 for <tls@core3.amsl.com>; Tue, 8 Jun 2010 08:50:56 -0700 (PDT)
Received: from smtp115.biz.mail.re2.yahoo.com (smtp115.biz.mail.re2.yahoo.com [66.196.116.35]) by core3.amsl.com (Postfix) with SMTP id E39663A69C3 for <tls@ietf.org>; Tue, 8 Jun 2010 08:50:55 -0700 (PDT)
Received: (qmail 1795 invoked from network); 8 Jun 2010 15:50:54 -0000
Received: from thunderfish.local (turners@96.231.124.63 with plain) by smtp115.biz.mail.re2.yahoo.com with SMTP; 08 Jun 2010 08:50:54 -0700 PDT
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: pSRiBPIVM1kFk8MaOaVkcnTd._3yNUQcLvvG_ryknrvfOoua2cGPRzcG_DPVPKugelmMPu0PW98iGYeAdr_aRcW8xONJVVhB42F..f4a9oOrJG7Lcc92OhKc_BhsqoC3d4ZwkPGk0Uh0yZ5lgYF74ewNI9zr3gQt6COdqbNnMsOABy_85632HAiTZIsoZH7qS7NzJx9vJjv13nxu4XwFeTut0TwIYymIveNzOcGX.i5YitHNA3rBIBMI6aBKQ_SPegkHtrNjsx2.yfLOQaatC8a1n2ln7m3t58lmDw5zvHEsb98p82d73xqDKidoiEse_tV_LvELkihDPmBzZe9V4ZEiI9OmWmJnbC9AddZO307Kq9o65IRoJmY95NH2dT2Mwk5pIjhGLvivCGmccmZqUf_.wPXlNVKn8jIyraR4sytjMMVPdokAv1R_NXzC8d_fhh7KjdP6G0dKVYnhKSEp6B_X
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4C0E66DE.6000108@ieca.com>
Date: Tue, 08 Jun 2010 11:50:54 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
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> <4C0DFC6C.3040508@gnutls.org>
In-Reply-To: <4C0DFC6C.3040508@gnutls.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 15:51:00 -0000

Nikos Mavrogiannopoulos wrote:
> Joseph Salowey (jsalowey) wrote:
>> 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. "
> 
> It is ok with me. My only reservation would be "... sending a
> warning-level unrecognized_name(112) alert is NOT RECOMMENDED ...". One
> might deduce, ok let's send some other alert to indicate the situation.
> I'd prefer "... sending any warning-level alert to indicate this
> situation is NOT RECOMMENDED ..."

If you're going to use "NOT RECOMMENDED" add it to section 1.2.  You 
could use something like*:

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
  NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
  "MAY", and "OPTIONAL" in this document are to be interpreted as
  described in [RFC2119].

* http://www.rfc-editor.org/errata_search.php?eid=499

spt