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

Michael D'Errico <> Fri, 04 June 2010 16:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8713E3A69A4 for <>; Fri, 4 Jun 2010 09:18:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.03
X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b7TIFzQn9HfK for <>; Fri, 4 Jun 2010 09:18:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 64B8E3A6875 for <>; Fri, 4 Jun 2010 09:18:21 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id AF25FB987B; Fri, 4 Jun 2010 12:18:06 -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=LyRzjk92F39R 4rFlTwtzm3mqaAk=; b=f60NivyUrNpgvoMn2vtrdUEeHyxIuDcO5e+Atuvliaig 0WQ5vcX2l48ecgQOz/aKG5vMnaUAOkXIc3uFkcu90tr20qktBgcixPApIzLDl3/A DWP4k7eW0QNSnl8pTqAmm3F8q1HA9+dRsPykGJU0OhW7dmnXqxRgtMzr0qvNBns=
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=wS4W2y YCYhxg8lr6VJZXNKyRJ4JTxF9685MuXHknOOXfnRmuWpt0a2OF3vCR7zgjqPTCvv 0T+kgVntLYI+P9beac2C25gijBjwxxBp3y6LkLWvNyi7oEaj8WlZdqckQV7t15Y4 sk6gxQTk8qnqVsotLTTl6ezySAIGI0CTrN2U0=
Received: from a-pb-sasl-quonix. (unknown []) by (Postfix) with ESMTP id 8BB00B987A; Fri, 4 Jun 2010 12:18:04 -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 0AE3FB9879; Fri, 4 Jun 2010 12:18:00 -0400 (EDT)
Message-ID: <>
Date: Fri, 04 Jun 2010 09:17:59 -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: C104C1C4-6FF4-11DF-B718-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: Fri, 04 Jun 2010 16:18:23 -0000

I would like to see text that says a peer SHOULD ignore warning alerts
that it doesn't otherwise handle.  Clearly the peer that sent the alert
with a warning level doesn't think it's a showstopper -- if it was a
problem, the alert level would have been fatal.

Peers that escalate a warning to fatal are not playing nice; they are
causing other software to abandon the practice of sending warnings even
though they could prove useful.  Just because you can't imagine why a
warning alert would be useful, today, doesn't mean that a use will never
be found for it.


Martin Rex wrote:
> Nikos Mavrogiannopoulos wrote:
>> 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?
> I think the issue is much more about API semantics.
> Most APIs are pretty binary, either they succeed, or they fail with
> a (numeric) error code.  The case "succeeds with a warning code"
> is fairly unusual for APIs, and very unusual to application programmers.
> Defining non-fatal error codes might be possible, but you don't know
> what exactly apps will do: will they simply ignore error codes that
> are classified non-fatal or will they abort on all error codes that
> they do not recognize.
> And as soon as you have several software/abstraction layers in your
> software architecture, the picture becomes more and more fuzzy,
> because you don't know whether intermediate layers are prepared
> to deal with non-fatal error codes and in particular non-fatal
> error codes that were defined after the intermediate layers
> were shippped.
> A warning-level "unrecognized_name" alert is useful for the receiver
> only when it is made available to the application on top of TLS in
> a clearly defined and consistent fashion.  If we want to allow
> warning-level "unrecognized_name" alerts, then we must define
> the API semantics for the receiving TLS implementation that
> its calling app is going to experience.  Otherwise, we should get
> rid of it (and use the fatal-level alert for the situation where
> the server is condigured to abort the handshake).
> -Martin