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

Marsh Ray <marsh@extendedsubset.com> Wed, 09 June 2010 17:26 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59DAC3A67B4 for <tls@core3.amsl.com>; Wed, 9 Jun 2010 10:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.092
X-Spam-Level:
X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77tADZ8vZXfJ for <tls@core3.amsl.com>; Wed, 9 Jun 2010 10:26:52 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 65ED73A69AE for <tls@ietf.org>; Wed, 9 Jun 2010 10:26:52 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OMP3F-0002RT-IU; Wed, 09 Jun 2010 17:26:53 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id AC29564D9; Wed, 9 Jun 2010 17:26:51 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+NAo8WtHCSk5iUfOwRQHDdiaJdEkr8jIQ=
Message-ID: <4C0FCED9.8050008@extendedsubset.com>
Date: Wed, 09 Jun 2010 12:26:49 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <4C0FA538.7050309@pobox.com> from "Michael D'Errico" at Jun 9, 10 07:29:12 am <201006091456.o59EukJ3015376@fs4113.wdf.sap.corp> <AC1CFD94F59A264488DC2BEC3E890DE50AA7E552@xmb-sjc-225.amer.cisco.com> <p0624083bc83572582a36@[10.20.30.158]>
In-Reply-To: <p0624083bc83572582a36@[10.20.30.158]>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jun 2010 17:26:53 -0000

On 6/9/2010 11:37 AM, Paul Hoffman wrote:
> 
> This is definitely more understandable than earlier revs. However,
> there is still not enough definitive wording. I propose:
> 
> The ServerNameList MUST NOT contain more than one name of the same 
> name_type.  If the server understood the ClientHello extension but 
> does not recognize the server name, the server SHOULD take one of
> two actions: abort the handshake by sending a fatal 
> unrecognized_name(112) alert, or continue the handshake using a 
> default credential.

Is it necessary to specify that the continued handshake SHOULD "use a
default credential"? TLS doesn't really require handshakes to use
credentals after all.

Perhaps this is extraneous overspecification?

If not, perhaps some clarification of the meaning of this term
"default credential" would be helpful. I'm not sure if this is what was
meant, but one possible rewording might be "or continue the handshake as
if the client had not specified a server_name extension."

> Sending a warning-level alert such as 
> unrecognized_name(112), but continuing the handshake, is NOT 
> RECOMMENDED because the client's expected behavior in response to 
> this is unpredictable.

I accept that I may be in the minority on this (I honestly don't see why
this case shouldn't be considered grounds for outright handshake
failure). Still, as a guy who writes app code on the client side, the
server side, and sometimes in between it seems to me like what we're
calling "unpredictable client behavior" here is really the effect of
conscious design decisions that made by implementers of TLS libraries
and client application code.

So if a modern SNI-aware client wishes to abort the handshake on
receiving the name mismatch warning, is it really appropriate for the
revised spec to attempt to defeat that by saying the server should
withhold this information from the client and the warning SHOULD NOT be
sent at all?

- Marsh