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

Michael D'Errico <> Mon, 07 June 2010 18:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9118D3A67D9 for <>; Mon, 7 Jun 2010 11:50:35 -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 QRSwWJI6EHzX for <>; Mon, 7 Jun 2010 11:50:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7FA9C3A67D6 for <>; Mon, 7 Jun 2010 11:50:31 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id EF39FBA804; Mon, 7 Jun 2010 14:50:30 -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=YsRvPXnxf0M5 G/kv2kFerC2J/BY=; b=NRoeWMg0R2Nf+DxudPzZpHtbXBZ6cGMOnOnfKA+5reVY s/hKKlf3eGCSwbtpdd2+Sy/p3c5ceTFo6VhK1a7GJ1IPY5+roURikSCwyh+rxgCd tAbuQU1UzusyBwjawE+26KB7yeA5jrBoXXX9d6QsPXbcaLwQGLl2uILX69nSCQU=
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=ZwS7cZ m7CNkCM6RF0Cq+Ukol/Ky3JhP4SHRH01iidhOwDt36hJIv2MJ0RnlKlHilssu228 /MoI5sKIeZDhOM0qIGQwSa1y0dpfLRzHFtNfJZEkhtJj6lM7bsA9Ed/QgIxqc2HZ gTI2lF0i2MAKvrHqeaouDwtPOVukDE/mUHslg=
Received: from a-pb-sasl-quonix. (unknown []) by (Postfix) with ESMTP id C7CD5BA803; Mon, 7 Jun 2010 14:50:28 -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 CDDF6BA802; Mon, 7 Jun 2010 14:50:24 -0400 (EDT)
Message-ID: <>
Date: Mon, 07 Jun 2010 11:50:23 -0700
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20090812)
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 8AA75BAA-7265-11DF-A8C5-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 18:50:35 -0000

Nikos Mavrogiannopoulos wrote:
>> 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).

Paypal is who decided that DES3 was not acceptably secure for them.  I am
not suggesting that TLS can decide what is right for every application.

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

They allowed DES3 to be negotiated, but then in the application they sent
an HTML error page if the cipher suite used it.  The idea was apparently
that they thought they could present a better error message than a browser
would if they simply failed with a handshake_failure alert.

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

It may be, but having more than one data point is better.  Why suppress

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

In a past life I wrote email server software.  I was very young, new to
standards groups, even very new to programming.  I used to argue against
things that I didn't understand very well because they sounded difficult
to implement or I couldn't see their potential usefulness.  It was wrong
for me to try to impose my own limitations on others who were much more
capable than I was at the time.  Fortunately I didn't cause any permanent

However, I see the opposite happening here.  I've put hundreds, maybe
thousands of hours into my TLS implementation and have thought through
every last detail.  I would love to have many more alerts added to TLS
(some warning, some fatal, maybe some both) to aid in diagnosing why
connections don't succeed, or perhaps why they succeeded, but maybe not
in the way they should have (e.g. with Paypal's former behavior).

It's frustrating to have to defend a feature that already exists in TLS
from people that want to scrap it simply because they personally haven't
found a use for it.