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

Martin Rex <> Mon, 07 June 2010 19:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6469E3A672E for <>; Mon, 7 Jun 2010 12:46:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.649
X-Spam-Status: No, score=-7.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zjQp7l2y9BpH for <>; Mon, 7 Jun 2010 12:46:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 476F63A67D6 for <>; Mon, 7 Jun 2010 12:46:24 -0700 (PDT)
Received: from by (26) with ESMTP id o57JkCpp025889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jun 2010 21:46:12 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
To: (Michael D'Errico)
Date: Mon, 7 Jun 2010 21:46:11 +0200 (MEST)
In-Reply-To: <> from "Michael D'Errico" at Jun 7, 10 10:53:35 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
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 19:46:29 -0000

Michael D'Errico wrote:
> 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.

I am sorry for again being ambiguous in my descriptions.

This wording is supposed to apply to >>TLS client implementations<<,
and these are supposed to completely ignore warning-level alerts and
continue the TLS handshake.  Whether or not the resulting TLS session
characteristics meet the expectations or policy of the calling application
is an entirely different matter and up to the application to decide.

The client application can do _nothing_ useful with a warning-level
alert "unrecognized_name" other than show it to a user or write it
to a logfile.  In both situations, it MUST NOT stall the ongoing
handshake, but instead either abort (sending a fatal handshake alert)
or ignore and continue this handshake.

A non-negligible amount of the installed base of browsers (~50%) and
programmatic clients is not going to send an extension SNI, so servers
will likely have to provide something sensible for that situation anyway,
and for quite some time to come -- entirely without that alert.