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

Michael D'Errico <> Mon, 07 June 2010 17:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1613E3A6880 for <>; Mon, 7 Jun 2010 10:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tMdu5Av4CuTL for <>; Mon, 7 Jun 2010 10:55:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 834303A67AD for <>; Mon, 7 Jun 2010 10:53:42 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 7E2FCB9F29; Mon, 7 Jun 2010 13:53:42 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=JYsMi5OCUPUh cOxsu3h2+7hoAaM=; b=fMGYHP57kOcGQFiU9MKOff/BS8MAZUX23t2TNmlh2lC7 DZaVRhcXQBWlLa5PYEop/V9A4WvSmSeUOhWKZJhf+czfrpm4Xvf68Gw/+X2BqcnZ S7yVpQXKu3DZwTdYVxRqJYxJw3RJs/CYNODegmNKgab0mm7AQpA7ZwCbvOBLmvg=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=Eg3DcT QdMbCn4WpaQc24VpeoIFKNell/aKkoekd9cmR0IydM/jREPwn2SBJTIuyLWb4HFd u1Xx6ESBxwFcdYBesi8WlbymTBaI4xW+K7jeJrm62ZyWFvZeP5/fRq4xY455cSTN jSSgV4c5ts4PJ3ZpqepswO3RXHQL3Vk2SejJU=
Received: from a-pb-sasl-quonix. (unknown []) by (Postfix) with ESMTP id 59DCDB9F28; Mon, 7 Jun 2010 13:53:40 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6C9D3B9F23; Mon, 7 Jun 2010 13:53:36 -0400 (EDT)
Message-ID: <>
Date: Mon, 07 Jun 2010 10:53:35 -0700
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20090812)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 9B0F0EFA-725D-11DF-8AC1-6730EE7EF46B-38729857!
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 17:55:27 -0000

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.

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) and then the server application would display
its error message in the HTML sent to the client.  The client's low-level
TLS code could be interrogated as to whether anything strange occurred
and it would be able to provide an answer.

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.

However I disagree with your wording:

    A client that receives a warning-level "unrecognized_name" alert
    SHOULD ignore this alert and continue the TLS handshake.  The purpose
    of a warning-level "unrecognized_name" is for diagnostic purposes,
    if anything.

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.