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

Martin Rex <mrex@sap.com> Mon, 14 June 2010 14:02 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 219EC3A68B6 for <tls@core3.amsl.com>; Mon, 14 Jun 2010 07:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.688
X-Spam-Level:
X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_50=0.001, 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 dAm0rU8LADXt for <tls@core3.amsl.com>; Mon, 14 Jun 2010 07:02:18 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 197703A68ED for <tls@ietf.org>; Mon, 14 Jun 2010 07:02:17 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o5EE2KAa015879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Jun 2010 16:02:20 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201006141402.o5EE2IIi026247@fs4113.wdf.sap.corp>
To: mike-list@pobox.com (Michael D'Errico)
Date: Mon, 14 Jun 2010 16:02:18 +0200 (MEST)
In-Reply-To: <4C12BD12.1020900@pobox.com> from "Michael D'Errico" at Jun 11, 10 03:47:46 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, 14 Jun 2010 14:02:19 -0000

Michael D'Errico wrote:
> 
> Martin Rex wrote:
> > 
> > SNI is _not_ a naming service.  It is not even a part of TLS itself.
> 
> I have no idea what point you're trying to make here.  What gives you
> the idea that the server name extension is not a part of TLS?


> > RFC-5246 is pretty clear about this (last sentence of section 1):
> > 
> >    the decisions on [...] how to interpret the authentication certificates
> >    exchanged are left to the judgment of the designers and implementors
> >    of protocols that run on top of TLS. 

>
> It's apparent that you don't understand what SNI is for.  TLS absolutely
> needs to know which domain name a client is trying to connect to so that
> an appropriate certificate chain can be selected.

No, it doesn't.  It is a clear violation of the architecture if TLS
itself messes around with the names in certificates.

TLS does not need to know anything about DNS (server) names involved
in a communication.  That is, and has always been, clearly specified
by all versions of TLS to be entirely an application matter.

Even if may TLS implementations today provide helper functions to
applications for performing server endpoint identification, it is still
a matter of the application to make use of these function, or to
perform endpoint identification in a completely different fashion.


-Martin