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

Peter Sylvester <peter.sylvester@edelweb.fr> Mon, 14 June 2010 19:18 UTC

Return-Path: <peter.sylvester@edelweb.fr>
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 1EA2B3A697A for <tls@core3.amsl.com>; Mon, 14 Jun 2010 12:18:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.139
X-Spam-Level:
X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_40=-0.185]
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 7w2IcEQJnAsj for <tls@core3.amsl.com>; Mon, 14 Jun 2010 12:18:23 -0700 (PDT)
Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id E6C443A6948 for <tls@ietf.org>; Mon, 14 Jun 2010 12:18:22 -0700 (PDT)
Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id 055A696 for <tls@ietf.org>; Mon, 14 Jun 2010 18:09:26 +0200 (CEST)
Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 39F5717061 for <tls@ietf.org>; Mon, 14 Jun 2010 18:09:24 +0200 (CEST)
Received: from [192.168.0.24] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 1278877D8 for <tls@ietf.org>; Mon, 14 Jun 2010 18:09:14 +0200 (CEST)
Message-ID: <4C1653F8.3020209@edelweb.fr>
Date: Mon, 14 Jun 2010 18:08:24 +0200
From: Peter Sylvester <peter.sylvester@edelweb.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4
MIME-Version: 1.0
To: tls@ietf.org
References: <201006141402.o5EE2IIi026247@fs4113.wdf.sap.corp>
In-Reply-To: <201006141402.o5EE2IIi026247@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Mon, 14 Jun 2010 19:18:24 -0000

> 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.
>    
... and a server doesn't need to have a DNS name at all.

I am not whether I understand (or ever understood) what
SNI is for, at least I'd say that if an application protocol that
uses dns names to identify different application level endpoints
(which is common due to ip address shortage),
and if the application wants to use different TLS protection
mechanisms for each of the endpoints, or , when the
client part would expect this as a possibility, either in general
for the application or in particular for the intended
communication, the  client protocol client needs
a way to communicate the desired dnsname to TLS layer
and to the application entity,  the latter not necessarily in theory
if TLS is always used. SNI is one way to do the first.

A priori, it has nothing to do with certificates,
in SRP/TLS authentication one may not even have such things,
in practice, for at least one not totally unimportant protocol,
the only "visible" effect is the usage of different certificates to
be used for authentication.

an (theoretical) application protocol for example could
require an IP matching address in order to recognize
a server endpoint.

Peter