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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Fri, 04 June 2010 05:43 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 432E23A6842 for <tls@core3.amsl.com>; Thu, 3 Jun 2010 22:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Level:
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
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 I1JBgHEUvmRg for <tls@core3.amsl.com>; Thu, 3 Jun 2010 22:43:25 -0700 (PDT)
Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by core3.amsl.com (Postfix) with ESMTP id 304063A68E9 for <tls@ietf.org>; Thu, 3 Jun 2010 22:43:25 -0700 (PDT)
Received: by ewy1 with SMTP id 1so204998ewy.13 for <tls@ietf.org>; Thu, 03 Jun 2010 22:43:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=SFmKdBIRHKs0iXFyLdQd2NQ3hlTUWKG1t3VZ4nZOUwM=; b=LblJbUVsAiSui8hUjGbstM1ciA/rzz19hpHTgUqyit4bFK2RJXWLX9Zczz74hh/n0n Z5edTc4zXxNY2FwfttLQwISgyt/O8olaS9EzhcO1UX1rRk2tkTgO1ZQg2vWY02/aPvSX pgzjTwcSAXV2ns+el3UyJuk6LBHn4Fks9pb+k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=C3Ar+cGIqI7FHHNZyKB1XV0e2JEJa7cCm6baCvKfWfqyoPAzn2wR9kFXRfgCMvgQ4z e6er35HynAYyfQkHgFxDzQjSDQuidqlaDn+ix4CR+dzb5CdXIIMb1X2LYsAYPoxEtOEB mnTWuABGwtG+0n+0tmwEtUP6Dbxm4xH0Auzp8=
Received: by 10.213.34.3 with SMTP id j3mr7456157ebd.70.1275630188772; Thu, 03 Jun 2010 22:43:08 -0700 (PDT)
Received: from [10.100.2.14] (78-23-67-218.access.telenet.be [78.23.67.218]) by mx.google.com with ESMTPS id 15sm483257ewy.0.2010.06.03.22.43.07 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Jun 2010 22:43:08 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4C08926B.2080107@gnutls.org>
Date: Fri, 04 Jun 2010 07:43:07 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Michael D'Errico <mike-list@pobox.com>
References: <201005251657.o4PGvZkE006346@fs4113.wdf.sap.corp> <4BFC0FB9.5030908@pobox.com> <AC1CFD94F59A264488DC2BEC3E890DE50A9ED6F5@xmb-sjc-225.amer.cisco.com> <AANLkTilRO_rj68yZlX3WenciASNybJqHTSsnIMHHoLBU@mail.gmail.com> <AC1CFD94F59A264488DC2BEC3E890DE50A9ED759@xmb-sjc-225.amer.cisco.com> <op.vdqdftkkvqd7e2@killashandra.oslo.osa> <4C07E49D.3010700@pobox.com>
In-Reply-To: <4C07E49D.3010700@pobox.com>
X-Enigmail-Version: 0.95.7
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
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: Fri, 04 Jun 2010 05:43:26 -0000

Michael D'Errico wrote:
> I agree with Yngve that a server should send either an empty SNI
> extension OR an unrecognized_name alert but not both.  However, I
> disagree that the server SHOULD NOT send a warning alert since that
> hides information from the client.
[...]
>     1 - server understood the SNI and used it to select an appropriate
>         certificate chain and other parameters
>     2 - server understood the SNI but did not recognize it as one of
>         its configured virtual hosts; however, the server is set up
>         to use a default configuration in that case
>     3 - server understood the SNI but did not recognize it as one of
>         its configured virtual hosts; there is no default configuration
>         available so the handshake can not continue
>     4 - server does not understand the SNI extension
> 
> The way my server reacts to each of these cases is:
> 
>     1 - add an empty SNI extension to ServerHello
>     2 - send a warning unrecognized_name alert
>     3 - send a fatal unrecognized_name alert
>     4 - send nothing
> 
> Yngve would prefer that nothing is sent in case 2, but then a client
> can not distinguish it from case 4.

I believe that his point was, what can the client do anyway? In both
cases the client just follows the handshake and will be prompted if the
"default" certificate doesn't match the connected host. Would the client
need to be warned that he is being connected using the "default"
certificate rather than any specific?


regards,
Nikos