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

Martin Rex <mrex@sap.com> Fri, 04 June 2010 19:51 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 026433A6823 for <tls@core3.amsl.com>; Fri, 4 Jun 2010 12:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.828
X-Spam-Level:
X-Spam-Status: No, score=-7.828 tagged_above=-999 required=5 tests=[AWL=0.562, 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 DS1YSEO49Rz9 for <tls@core3.amsl.com>; Fri, 4 Jun 2010 12:51:25 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id CF0703A677D for <tls@ietf.org>; Fri, 4 Jun 2010 12:51:24 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o54Jp6Or019685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Jun 2010 21:51:06 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201006041951.o54Jp5Kw005001@fs4113.wdf.sap.corp>
To: jsalowey@cisco.com (Joseph Salowey)
Date: Fri, 4 Jun 2010 21:51:05 +0200 (MEST)
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE50A9EDDA1@xmb-sjc-225.amer.cisco.com> from "Joseph Salowey" at Jun 4, 10 10:37:02 am
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: Fri, 04 Jun 2010 19:51:26 -0000

Joseph Salowey wrote:
> 
> The discussion in 5246 indicates that the warning messages are
> unpredictable.  I don't think we can solve this problem in this document
> so we wither discourage the warning in this case or we just explain the
> unpredictability.  Below are two proposed text change to paragraph after
> the structure definition in section 3 in draft-ietf-tls-rfc4366-bis-08.
> Let me know which you prefer soon as we need to get this document
> finished, because other documents are waiting on it.  

I do agree that we're talking about an extension (SNI) and an alert
for an existing spec (rfc4366) and an existing installed base,
so describing the risk of sending a warning-level "unrecognized_name"
alert to clients is sensible and appreciated.

Still, I think we have to document what _clients_ SHOULD and SHOULD NOT
do when receiving a warning-level "unrecognized_name" alert.  This was,
and still is not clear from the specification, rather it is essentially
undefined  (it is _not_ implementation defined, because a server
can not reliably distinguish individual peer client implementations by
looking at the contents of the ClientHello handshake message it sent).


-Martin