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

Michael D'Errico <mike-list@pobox.com> Wed, 09 June 2010 18:14 UTC

Return-Path: <mike-list@pobox.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 EC21D3A699A for <tls@core3.amsl.com>; Wed, 9 Jun 2010 11:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.074
X-Spam-Level:
X-Spam-Status: No, score=-1.074 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_05=-1.11]
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 7nDyC-+rTORc for <tls@core3.amsl.com>; Wed, 9 Jun 2010 11:14:39 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 2CB6A3A6878 for <tls@ietf.org>; Wed, 9 Jun 2010 11:14:35 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 4B5A8BA642; Wed, 9 Jun 2010 14:14:36 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=e/x9YVu8Ovwe oz946/++WVWgBPM=; b=Hrr4K+U70EtDiOnbTKkfSw1rDACo0SXX5GlPQD6uySM2 Qvb25eUXi24hYP/ic2y+2ncSYbVT47xrymdsJW51mld58avkdA6n9JqhSWJkwVC8 DqPFrOi+YqF7Xbm/jxPgaIkauHl8q8tvBkmo/p98NhLG5NYUUnrrsqMx686Gx6g=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=Cb6UoS yKkiDbUmI17bM41Pr01IhM94ICjgHHbc9881CJSI5WZUTAgYVrbDVnwR/9fRSdvu bBA95LZZ1If6kxYFSqXcXsv+pTPxaoG1u6yyIgX0qXkLz6bDJb94gUVwwP9JcSp2 KDDI/IxNNPUjMZbu3xSwZtAzS+8hFAHE4H118=
Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 380FABA641; Wed, 9 Jun 2010 14:14:35 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 84C77BA640; Wed, 9 Jun 2010 14:14:33 -0400 (EDT)
Message-ID: <4C0FDA08.90904@pobox.com>
Date: Wed, 09 Jun 2010 11:14:32 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Marsh Ray <marsh@extendedsubset.com>
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]> <4C0FCED9.8050008@extendedsubset.com>
In-Reply-To: <4C0FCED9.8050008@extendedsubset.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: DBD7069A-73F2-11DF-8FEA-9056EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com
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 18:14:41 -0000

Marsh Ray wrote:
> 
> 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.

Let me try another approach.

Now that you know that my server code might send an unrecognized_name
warning alert to you in some very limited circumstances, what will you
do in your client code?  Since you don't care about this particular edge
case, the sensible thing is for you to ignore it.

Here's some pseudo-code:

     if (alert_level is fatal)
     {
         abort handshake;
     }
     else if (alert_level is not warning)
     {
         abort handshake;  // protocol error
     }
     else if (alert is close_notify)
     {
         forward EOF to application;
     }
     else
     {
         // ignore warnings we don't care about
     }

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

The ability to send a warning-level unrecognized_name alert is in the
current spec (RFC 4366).  You are arguing that since you don't care
about the information it conveys that we should ban it.

Mike