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

Michael D'Errico <> Mon, 07 June 2010 20:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BC533A67E6 for <>; Mon, 7 Jun 2010 13:51:29 -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 L373safPOCTh for <>; Mon, 7 Jun 2010 13:51:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C054E3A67B1 for <>; Mon, 7 Jun 2010 13:51:27 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 19A2EB9E12; Mon, 7 Jun 2010 16:51:28 -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=cuT4z0pDL7AL TCs+CklDHNZe7Eo=; b=yIK/1uBuebNq95V+5GPmAbxxHgrS2r8OcrBTK3uunRCI IX6XtDoG3+9anrLU7NJzVjpkKNsaDrM2M7Xv3rNhMVdU0xEtr7BI0R3XJjNxJPmj vC279VloA84QYdAAXjYlkc13EInaZel4zVbxAOrQmccJrOkhPQ9hvBjDtGmoMjo=
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=OqWVrP e+lkoT3B/yyXT39d+9OqLY0EdrXl9S2fs4TmKU+kGgvp55XfihF7+YgfcfrZFO/C Kopa7IUinDrWt535xM7nK500++3FLEWFPtlwt1apv21BAosjn4UzZONTQW5enKnS fMq92MkO/rIKFzWG3F0R01PA9DlrR37T85jy8=
Received: from a-pb-sasl-quonix. (unknown []) by (Postfix) with ESMTP id 006AEB9E10; Mon, 7 Jun 2010 16:51:26 -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 32E9EB9E0F; Mon, 7 Jun 2010 16:51:24 -0400 (EDT)
Message-ID: <>
Date: Mon, 07 Jun 2010 13:51:23 -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: 70DD12B2-7276-11DF-8A9A-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 20:51:29 -0000

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

This may be a language problem.  I interpret a suggestion that a client
should "completely ignore" something, that it should throw it away and
behave as if it never saw it; doing anything with the information (even
just making it available to the application) would violate the protocol.

I'm saying that, yes, it should continue the handshake as if it never
saw the warning alert, but no it should not be forbidden from remembering
that it was received or from passing that information along.

> 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.

You don't consider being able to write an error message to a log file
useful?  I agree that showing this alert to an average user won't be
much help, but if they show it to their system administrator, there's
a chance that they would have a clue as to the problem.

> 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.

Eventually they will all be sending SNI or will perish.  IPv4 space
is running out fast.  But this is a straw man since the alert is not
sent to a client that doesn't send SNI at all.