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

Nikos Mavrogiannopoulos <> Mon, 07 June 2010 18:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDBAC3A67AC for <>; Mon, 7 Jun 2010 11:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fl13-+HYLstu for <>; Mon, 7 Jun 2010 11:06:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D9A813A67AD for <>; Mon, 7 Jun 2010 11:06:07 -0700 (PDT)
Received: by ewy1 with SMTP id 1so816315ewy.13 for <>; Mon, 07 Jun 2010 11:06:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=0XmP83BA0uLGXc+AJvgHT/5PpSVudz40h1C6BHHaw+4=; b=qBkMeSzV+FPs9bZ7TRnTTfAlEGBeQvkDLICFIUvrxBh09jEPZBX87qhUnklCGkvQ/D vorrOzKf2pUopQ1DltiktjjRiXk+N6QqQ5S9ja5Rk4M4JN6y/6HbYrDHsTL12Y/s+zNQ oLX+tPZf19QlSH1XQ0/zhSZ4cSCACztaqnvmw=
DomainKey-Signature: a=rsa-sha1; c=nofws;; 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=hzOFKHney9KG+EVJ9i5IlvZOtsNg7yTBZ/hnsyGbmlgLZsoxeuCDofU1tX/Jor35Cv u4oSRvh5dQZC0lZ0a77dxUAct/uZG/MMsV9zL0/GzkJgq9GsEc4JuPLvVk/NTg/0m2t2 rv+3inprySjF6nGI+ozyphEb1ynXjOYXxTitk=
Received: by with SMTP id k6mr1085230ebk.54.1275933960909; Mon, 07 Jun 2010 11:06:00 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id 14sm2824008ewy.10.2010. (version=SSLv3 cipher=RC4-MD5); Mon, 07 Jun 2010 11:06:00 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <>
Message-ID: <>
Date: Mon, 07 Jun 2010 20:05:59 +0200
From: Nikos Mavrogiannopoulos <>
User-Agent: Thunderbird (X11/20100411)
MIME-Version: 1.0
To: Michael D'Errico <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Jun 2010 18:06:10 -0000

Michael D'Errico wrote:
> Martin Rex wrote:
>> I actually fail to see the exact purpose of a warning-level alert
>> "unrecognized_name".  The client is supposed to perform the server
>> endpoint
>> identification in any case, and that warning should not affect the
>> outcome of that process at all.
> I feel like I'm "guilty until proven innocent" on this one.
> Have you ever connected to a secure site only to have the HTML contain a
> warning that inadequate security was established?  This used to happen
> if you connected to with DES3 (but now it is just closing
> the connection).  The purpose of that behavior was to give the end user
> more diagnostic information than they get when the connection is merely
> dropped after sending a fatal handshake_failure alert.

TLS doesn't handle this. TLS doesn't even specify a security level for a
connection (and it isn't easy to).

> It would help if a no_common_ciphers alert was added to TLS.  That alert
> would be sent when the server doesn't support any of the client's
> proposed cipher suites.  It could also be used at the warning level in
> the case of paypal's former behavior.  The handshake would complete
> (after sending the warning)

How would it complete if they don't have common ciphers?

> The unrecognized_name warning alert can provide similar information to a
> client application.  If something goes wrong and the client application
> is looking for a reason why, it can ask the TLS layer if anything strange
> happened.  If this warning alert was received, that information might
> help the client diagnose the problem and determine what corrective action
> to take.

For the current example it is obvious what went wrong by viewing the
certificate sent isn't it?

> Clearly you don't see much use for this alert, but you should not impose
> that bias on others.  It is up to the application to decide what to do
> with the facilities provided by the TLS protocol.

I think it is important to have a good case of a thing to be handled in
code. If a TLS warning alert is _never_ going to be used, or it does not
provide valuable information to the peer. However if you think that this
information is valuable and it might even save debugging time for
implementors then I think it would be a nice opportunity to reconsider
(at least for me). Otherwise I think that the information provided by
this alert is redundant since it can be also seen by the certificate sent.