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

Martin Rex <mrex@sap.com> Mon, 14 June 2010 19:57 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 6B2F63A6936 for <tls@core3.amsl.com>; Mon, 14 Jun 2010 12:57:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.697
X-Spam-Level:
X-Spam-Status: No, score=-7.697 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 tmrC5XjQxKnu for <tls@core3.amsl.com>; Mon, 14 Jun 2010 12:57:49 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C6C533A68A3 for <tls@ietf.org>; Mon, 14 Jun 2010 12:57:48 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o5EJvpmn008631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Jun 2010 21:57:51 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201006141957.o5EJvoCp020921@fs4113.wdf.sap.corp>
To: mike-list@pobox.com (Michael D'Errico)
Date: Mon, 14 Jun 2010 21:57:50 +0200 (MEST)
In-Reply-To: <4C164C84.4000502@pobox.com> from "Michael D'Errico" at Jun 14, 10 08:36:36 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
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 19:57:50 -0000

Michael D'Errico wrote:
> 
> Martin Rex wrote:
> > 
> > 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.
> 
> There is never a clear line you can draw between one layer and another,
> such that no TLS layer will ever reach higher toward an application, or
> that no application will reach lower toward the TLS layer.

The architecture has very clear lines.

Where there is often a less clear line in in software modularization.
The latter is not necessarily a problem.  But the software modularization
should be perfectly clear of whether something is a core protocol function
or a helper/convenience function for the application to facilitate the
applications part of the job.

> 
> In my TLS code, there is a simple configuration scheme that applications
> use to tell the TLS layer which domain names map to which certificate
> chains.

That sounds fine to me.  You're saying that applications tell the TLS layer
which domain names map to which certificate chains/credentials.
That is just what I've been asking for.

Whether the credentail selection during the handshake is performed
through application-supplied preconfiguration involving helper/convenience
functions (that might be supplied by the TLS implementation), or through
some callback entirely within the server application code in an
implementation detail.


>
> Once set up, the application doesn't need to do anything more
> since the TLS code then handles certificate selection based on the SNI,
> version, cipher suite, supported signature algorithms, and key usage.
> It's quite complicated.

I don't think it is complicated.

The application supplies credentials and provides the necessary
information or guidance how to map client-supplied server_name
values to server credentials.  The server TLS implementation
needs to ensure that the credential can be used with the other
cryptographic parameters in ClientHello.  If there is more than
one credential available, more than one may match the selection
criteria, so there usually is a server-side preference order for
the server credentials.


> 
> You might condemn this as some sort of layering violation, but it really
> does make life easier for application writers.  I wrote the code once
> instead of requiring every application writer to have to reinvent it.

What you describe does not look like a layering violation to me.

In principle, it should be possible to implement SNI in TLS in a fashion
so that applications can invent and use new server_name types without
any changes to the TLS implementation.


-Martin